py27-omniORBpy pre-built binary trouble

[Thomas G Lockhart]

On Sep 7, 2014, at 8:11 PM, Bradley Giesbrecht <pixilla at macports.org> wrote:

> 
> On Sep 7, 2014, at 4:56 PM, Thomas G Lockhart <tlockhart1976 at gmail.com> wrote:
> 
>> 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?
> 
> 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)
>