Python and SWIG support in ports?

[Kubilay Kocak]

On 5/12/2015 1:44 PM, Kubilay Kocak 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.
> 
>> In our ports, we name our swig binaries things like
>> "/usr/local/bin/swig2.0" or
>> "/usr/local/bin/swig3.0".  How do we deal with this in Python ports which
>> use
>> SWIG?
> 
> If this is the case, it would mean all swig dependent things are also
> broken. How are other ports dealing with it, or working? This might
> provide some insight.
> 
> The if os.name == "posix": branch could do the same swig
> version-suffixed binary checking that the elif os.name == "nt":
> condition branch does.
> 
> A smarter way might *also* be to add functionality to that swig method
> to allow the system to provide the binary path/name via envvars or
> command line argument to (build,build_ext) commands explicitly.
> 
> I suggest creating an upstream issue.

By upstream I mean @ Python.

>> If possible, I'd like to push a fix upstream for FreeBSD, if the upstream
>> maintainer
>> is OK with it.

Also, another temporary workaround/option might be to implement a custom
build_ext command in M2Crypto that does a smarter find_swig

> Hit us up on IRC (#freebsd-python) if you'd like to talk more, or have
> questions
> 
>> Thanks.
>>
>> --
>> Craig
> 
> 
> 
>