Python and SWIG support in ports?

[Kubilay Kocak]

On 9/12/2015 4:53 AM, Craig Rodrigues wrote:
> On Fri, Dec 4, 2015 at 6:44 PM, Kubilay Kocak <koobs at freebsd.org
> <mailto:koobs at freebsd.org>> wrote:
> 
>     On 5/12/2015 9:40 AM, Craig Rodrigues wrote:
>     > Hi,
>     >
>     > I am working with the upstream maintainer of M2Crypto (
>     > https://gitlab.com/m2crypto/m2crypto ).
>     >
>     > In the distutils that comes with Python, the swig binary is harcoded
>     > to "swig" if on a POSIX system:
>     >
>     > https://hg.python.org/cpython/file/v2.6.2/Lib/distutils/command/build_ext.py#l635
> 
>     Short-term, swig20 could provide a symlink to the versioned binary until
>     a 'more correct' and permanent fix can be made.
> 
>     I'm not sure what to do about those ports that depend on swig30 in the
>     presence of swig20 also being installed, given they don't appear to
>     CONFLICT_INSTALL on each other. They both can't provide the swig
>     symlink. Supporting swig in DEFAULT_VERSIONS doesn't sound right and is
>     probably overkill.
> 
> 
> Actually, fixing the swig port in this way with a symlink is not a bad
> idea at all.
> I've looked at multiple platforms (Linux, OS X, Windows)
> and they all install a binary "swig".
> Pushing an upstream fix to Python distutils just to appease FreeBSD may
> not work out.
> 
> The down side of this change would be that you would not be able
> to install swig1, swig2, and swig3 at the same time, but that might be OK.
> 
> --
> Craig

The correct thing to do is be PEP-394'ish compatible (even though swig
itself isnt a python package). Again swig20 is a short term solution.

The root cause is technically an inadequate 'find the binary file name'
method.

We do want to keep/allow concurrent swig install support if they don't
already CONFLICT_INSTALL