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? - Tom _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
