omniORB @4.1.6 +python27 New upstream version and python version

[lockhart (Thomas Lockhart)]

omniORB-4.1.6 is available. This does not build with clang++ (other tickets document this issue) but does build with llvm-gcc-4.2. Patches to the Portfile are included to effect an update.

[lockhart (Thomas Lockhart)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

You cannot just indiscriminately set the compiler to llvm-gcc-4.2; that will break builds on Tiger, and probably isn't necessary with Xcode 3. See PortfileRecipes#compiler for how we usually handle this. Anyway this will be dealt with in #32062.

[lockhart (Thomas Lockhart)]

Replying to ryandesign@…:

You cannot just indiscriminately set the compiler to llvm-gcc-4.2; that will break builds on Tiger, and probably isn't necessary with Xcode 3. See PortfileRecipes#compiler for how we usually handle this. Anyway this will be dealt with in #32062.

OK, thanks for the feedback. How are ports updated for new upstream versions? Is opening a ticket like this the right way to do it? 4.1.6 has been available since 2011-07-01 and it would be nice to stay current with what is available. I'll look at making the compiler choice conditional and post new patches, and carry along my own local ports repository to allow more testing. More feedback and direction is welcome. hth

[neverpanic (Clemens Lang)]

Replying to lockhart@…:

OK, thanks for the feedback. How are ports updated for new upstream versions? Is opening a ticket like this the right way to do it? 4.1.6 has been available since 2011-07-01 and it would be nice to stay current with what is available.

Yes, that's the way we usually take if the maintainer doesn't update the port or there is no maintainer.

I'll look at making the compiler choice conditional and post new patches, and carry along my own local ports repository to allow more testing. More feedback and direction is welcome.

You're on the right way, if you implemented the compiler change pattern Ryan mentioned your patch should be ready for committing. Btw, if you attach a patch feel free to add "haspatch" to keywords. Also we usually cc or assign to the maintainer if there is any. There's no need to cc yourself, because the reporter is always cc'ed (we're not the debian bugtracker here…) and the milestone field is only really interesting for bugs against base, because there is only one version of the ports tree and it's being upgraded in a rolling release fashion.

[lockhart (Thomas Lockhart)]

Replying to cal@…:

Replying to lockhart@…:

OK, thanks for the feedback. How are ports updated for new upstream versions? Is opening a ticket like this the right way to do it? 4.1.6 has been available since 2011-07-01 and it would be nice to stay current with what is available.

Yes, that's the way we usually take if the maintainer doesn't update the port or there is no maintainer.

I'll look at making the compiler choice conditional and post new patches, and carry along my own local ports repository to allow more testing. More feedback and direction is welcome.

You're on the right way, if you implemented the compiler change pattern Ryan mentioned your patch should be ready for committing. Btw, if you attach a patch feel free to add "haspatch" to keywords. Also we usually cc or assign to the maintainer if there is any. There's no need to cc yourself, because the reporter is always cc'ed (we're not the debian bugtracker here…) and the milestone field is only really interesting for bugs against base, because there is only one version of the ports tree and it's being upgraded in a rolling release fashion.

OK, I'm not sure I've found the right combination of checks for the compiler and xcode version. In the recipes there is the minimum_xcodeversion which I can use to constrain a single OS X release to a specific version of xcode. But I don't see how to obtain the actual version of xcode to be able to constrain it for Lion only. The recipe whose title suggests that this would be covered does not seem to actually address it. So at the moment I've got a disjointed set of checks: one for a minimum xcode only for Lion, and setting the compiler to llvm-gcc-4.2 if the compiler is currently set to clang. But the concern was that I only set this if we are on Lion. Help!

[lockhart (Thomas Lockhart)]

OK, Duncan Grisby provided a patch to get things to compile using clang. I'll post that here along with an updated Portfile. I think that should address all of the concerns raised to this point. Thanks for the help!

[lockhart (Thomas Lockhart)]

Update to 4.1.6 including applying an extra patch from Duncan Grisby.

[lockhart (Thomas Lockhart)]

Minor patch to suppress extra inline code which causes trouble with clang. The alternative is to use llvm-gcc which does not exhibit a problem.

[lockhart (Thomas Lockhart)]

Replying to lockhart@…:

omniORB-4.1.6 is available. This does not build with clang++ (other tickets document this issue) but does build with llvm-gcc-4.2. Patches to the Portfile are included to effect an update.

A new patch from Duncan Grisby (the omniORB developer) allows building with clang on Lion. Portfile and clang.patch have been posted here.

[stromnov (Andrey Stromnov)]

Hi. New omniORB 4.1.6 breaks +universal variant.

[lockhart (Thomas Lockhart)]

Replying to stromnov@…:

Hi. New omniORB 4.1.6 breaks +universal variant.

Hmm. I did not change anything directly connected to that. Will revert to 4.1.4 and see if that one actually works on Lion.

[lockhart (Thomas Lockhart)]

Replying to stromnov@…:

Hi. New omniORB 4.1.6 breaks +universal variant.

I tried the 4.1.4 port (after adding patches and python27 variant) and it fails trying to upgrade python27 to a universal variant. Under what circumstances is a universal installation useful? What scenario should be supported? Are there guidelines published somewhere on this to help me get oriented? atm I'm inclined to recommend dropping support for a universal variant.

[lockhart (Thomas Lockhart)]

OK, need some help with policy on universal variants. 4.1.4 is two years old, 4.1.6 builds and runs with this set of patches, and I don't have the resources to test universal variants since that seems to want to upgrade my other MacPorts modules to universal versions. Can someone else provide a test platform for the universal variant? What were the symptoms when trying to build the universal variant with 4.1.6?

[lockhart (Thomas Lockhart)]

Replying to stromnov@…:

Hi. New omniORB 4.1.6 breaks +universal variant.

Hello again. I'd like to make progress on this. Version 4.1.4 is 2.5 years old and the newer version builds and installs correctly on Lion. Are you offering to troubleshoot the +universal problem or should we disable it and get modern with the upstream version? This also wedges the update for omniORBpy to 3.6. Please advise.

[lockhart (Thomas Lockhart)]

Complete Portfile which installs Python libraries into /opt/local/Library/Frameworks/... rather than in /opt/local/lib/... since the latter is not in the macports python search path. Will post a similar update for omniORBpy. Also bumped the revision number.

[jmroot (Joshua Root)]

This was committed in r90176. Would compiling with -std=gnu89 not fix the inline problems though?