Date: Sat, 5 Dec 2015 13:46:55 +1100 From: Kubilay Kocak <koobs@FreeBSD.org> To: Craig Rodrigues <rodrigc@FreeBSD.org>, ports <freebsd-ports@freebsd.org>, freebsd-python@freebsd.org Subject: Re: Python and SWIG support in ports? Message-ID: <5662501F.10403@FreeBSD.org> In-Reply-To: <56624F9B.30508@FreeBSD.org> References: <CAG=rPVc6AA37NFJkP%2BGaB6Y4BQP4aBYRLGGtQ6qc3VbmC38Qsg@mail.gmail.com> <56624F9B.30508@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5662501F.10403>