py27-omniORBpy pre-built binary trouble

[Thomas G Lockhart]

On Sep 7, 2014, at 10:03 PM, Ryan Schmidt <ryandesign at macports.org> wrote:

> 
> On Sep 7, 2014, at 11:55 PM, Thomas G Lockhart wrote:
>> 
>> On Sep 7, 2014, at 9:38 PM, Ryan Schmidt wrote:
>> 
>>> On Sep 7, 2014, at 11:32 PM, Thomas G Lockhart wrote:
>>> 
>>>> btw, I’ve been occasionally playing with updating omniORB (and omniORBpy) to the latest versions. They have always failed to build and I’d figured it was some breakage in the code for MacOS, but it turns out to be a Portfile problem where /opt/local/include is put on the compiler command line before the build directory paths are listed. If there is an older version of omniORB already installed, and if the include files are not fully compatible, then the build breaks. I’m guessing that it was the stuff added to make sure that the MacPorts compiler flags are used, but the omniORB makefiles are not using things in the expected order. A bad side effect. Will start tracking that down now too…
>>> 
>>> That should be easy enough to fix by adding one line:
>>> 
>>> configure.cppflags-replace -I${prefix}/include -isystem${prefix}/include
>>> 
>>> Will test that now.
>>> 
>>> For background on this, see https://trac.macports.org/ticket/40656
>> 
>> Well, we’ve got both omniORB and py-omniORB upgraded to version 4.2.0. Thanks!!!!!!
> 
> Yeah those built for me without too much trouble, but I did not have the previous version installed so I had not seen the problem you saw.
> 
> Replacing the cppflags as above helped with one error, but another error remained. Rather than try to isolate and fix it, I added a build conflict in r125161.

Great. btw, it seems that the patch files are no longer necessary, though I have not yet done enough interoperability testing to be absolutely certain. I’ll open a ticket at some point to get them to go away.

> 
> 
>> Can we close out the issues (including a very old #23558) and get a fresh start on issues for these ports?
> 
> #23558 has not been resolved...
> 

And never will be. It is written on snow leopard, and involves a problem with the universal variant which has long since vanished from the Portfile (and will not be supported in the future unless someone else wants to do a lot of work to implement an increasingly obsolete feature).

Isn’t there a “won’t fix” resolution possible?

              - Tom