py27-omniORBpy pre-built binary trouble

[Thomas G Lockhart]

On Sep 7, 2014, at 2:44 PM, Thomas G Lockhart <tlockhart1976 at gmail.com> wrote:

> 
> On Sep 7, 2014, at 11:21 AM, Bradley Giesbrecht <pixilla at macports.org> wrote:
> 
>> 
>> On Sep 6, 2014, at 10:44 PM, Thomas G Lockhart <tlockhart1976 at gmail.com> 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