On Sep 7, 2014, at 4:56 PM, Thomas G Lockhart <[email protected]> wrote:
> On Sep 7, 2014, at 2:44 PM, Thomas G Lockhart <[email protected]> wrote: > >> >> On Sep 7, 2014, at 11:21 AM, Bradley Giesbrecht <[email protected]> wrote: >> >>> >>> On Sep 6, 2014, at 10:44 PM, Thomas G Lockhart <[email protected]> >>> wrote: >>> >>>> I’m configuring a new machine (running Mavericks) and notice that some >>>> packages I’m used to building from source are available as pre-built >>>> binaries. That is great. But one package, py27-omniORBpy, wants to put its >>>> python files under /opt/local/lib/ when installed using “port install >>>> py27-omniORBpy”, whereas the prerequisite package omniORB wants to put its >>>> python libraries under /opt/local/Library/ >>>> >>>> I’d expect both of these to install python code under /opt/local/Library/, >>>> and in fact py27-omniORBpy *does* do that when built from source using >>>> “port install -s py27-omniORBpy”. >>>> >>>> Any ideas on what might be causing these differences? >>> >>> A none default env var you have set? >> >> Ah ha! Not exactly, but... >> >> The omniORBpy software uses autoconf and the python discovery mechanisms in >> those m4 macros. And it looks like it falls back to using something based on >> the value of —prefix (/opt/local in our case?) if it does not find a python >> executable. If it does find one it expects to look up the library location >> using: >> >> from distutils import sysconfig; sysconfig.get_python_lib() >> >> I have my /opt/local/bin/python pointing at python2.7. And autoconf found >> that so my py27-omniORBpy worked just as intended. If I remove the default >> version of python: >> >> sudo port select —set python none >> >> then I see the same (incorrect) build behavior here. Autoconf can’t figure >> out what to use so falls back to using a library path based on the —prefix >> value. >> >> So any suggestions for locking in the value of a PYTHON environment variable >> or the actual python executable within a MacPorts variant? I would have >> guessed that the python PortGroup would have magically handled that, but >> that does not seem to be the case. > > OK, I’ve got a fix which involves setting the variable configure.python to be > equal to python.bin. > > Bradley, it looks like you have matched this up with a two-year old ticket > which was not on my radar even though I’m the one who opened it and provided > a patch! That previous ticket already has a Portfile.diff which should > probably be superseded by my new one (though the effect is identical, the new > one is a bit cleaner imho). > > Should I just replace the Portfile.diff and can we get this one closed out? Sure, I'll take a look, do you have the numbers for ticket(s)? Regards, Bradley Giesbrecht (pixilla)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
