On Sep 7, 2014, at 8:11 PM, Bradley Giesbrecht <[email protected]> wrote:
> > 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)? #35818 and I’ve just posted a patch. There has been some activity on this ticket (which I missed; my email address has changed) but afaict the patches already applied plus my small patch file just posted should be enough to get a self-consistent build. btw trac would not let me supersede the Portfile.diff which was already there so I just posted an additional one. Thanks for closing this one out! - Tom > > Regards, > Bradley Giesbrecht (pixilla) > _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
