Opened 13 years ago

Closed 12 years ago

#33226 closed update (fixed)

omniORB @4.1.6 +python27 New upstream version and python version

Reported by: lockhart (Thomas Lockhart) Owned by: stromnov (Andrey Stromnov)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc:
Port: omniORB

Description

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.

Attachments (3)

Portfile.diff (1.9 KB) - added by lockhart (Thomas Lockhart) 13 years ago.
Update to 4.1.6 including applying an extra patch from Duncan Grisby.
clang.patch (342 bytes) - added by lockhart (Thomas Lockhart) 13 years ago.
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.
Portfile (3.6 KB) - added by lockhart (Thomas Lockhart) 13 years ago.
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.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 13 years ago by lockhart (Thomas Lockhart)

Cc: lockhart@… added

Cc Me!

comment:2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: lockhart@… removed
Keywords: haspatch added; omniORB omniORBpy python27 removed
Milestone: MacPorts 2.0.4
Owner: changed from macports-tickets@… to stromnov@…

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.

comment:3 in reply to:  2 ; Changed 13 years ago by 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

comment:4 in reply to:  3 ; Changed 13 years ago by 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.

comment:5 in reply to:  4 ; Changed 13 years ago by 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!

comment:6 in reply to:  5 Changed 13 years ago by 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!

Changed 13 years ago by lockhart (Thomas Lockhart)

Attachment: Portfile.diff added

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

Changed 13 years ago by lockhart (Thomas Lockhart)

Attachment: clang.patch added

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.

comment:7 in reply to:  description Changed 13 years ago by 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.

comment:8 Changed 13 years ago by stromnov (Andrey Stromnov)

Hi. New omniORB 4.1.6 breaks +universal variant.

comment:9 in reply to:  8 Changed 13 years ago by 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.

comment:10 in reply to:  8 Changed 13 years ago by 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.

comment:11 Changed 13 years ago by 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?

comment:12 in reply to:  8 Changed 13 years ago by 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.

Changed 13 years ago by lockhart (Thomas Lockhart)

Attachment: Portfile added

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.

comment:13 Changed 12 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed
Version: 2.0.3

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

Note: See TracTickets for help on using tickets.