On 9/12/2015 4:53 AM, Craig Rodrigues wrote: > On Fri, Dec 4, 2015 at 6:44 PM, Kubilay Kocak <ko...@freebsd.org > <mailto:ko...@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 _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
