py27-omniORBpy pre-built binary trouble

[Bradley Giesbrecht]

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)?

Regards,
Bradley Giesbrecht (pixilla)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140907/a2372ce3/attachment.sig>