update pymol with gcc43 and gcc44 variants

[adfernandes (Andrew Fernandes)]

It took some tweaking, but pymol can be built with gcc43 and gcc44.

Note that the explicit -lstdc++ link is required since the pymol build script uses gcc as the linker even if some of the objects are c++ files.

I could have sworn that pymol, when built with the standard configure script was faster... but I think that might be my imagination.

howarth - is this okay with you?

[howarth@…]

Why exactly do we want gcc variants? The goal should be to migrate
the user base to the latest FSF gcc release whenever possible. At least that
is the approach in fink.

[adfernandes (Andrew Fernandes)]

You know, that's an excellent question... for which I have no answer. I've been using MacPorts for a while, and many ports support different compilers.

For some of my numeric code, I actually need those compilers; gcc-4.4 uses OpenMP 3, for example, which is something I've been playing with. I'm guessing that MacPorts doesn't want to force everyone to installing the latest gcc, but don't really know. (Personally, I'm in favor of doing so... too many variants makes for configuration headaches, but I'm not an expert on config managment.) Hmm... a quick google doesn't reveal a specific MacPorts policy for this... but I do know that lots of ports do have options for building with different compilers.

IMHO, the variants are worth it just to show how to build with the non-default gcc-4.0 compiler on Leopard.

[howarth@…]

Considering that the primary use of the gcc4X packages is
to obtain the gfortran compiler whose features and performance
only increase with each FSF gcc release, it is much better
to try to migrate the users to the newer FSF gcc release as soon
as possible. That is the approach on fink anyway. It also has the
advantage of focusing attention on those packages which need adjustments
for the newest gcc4X release. I would much rather see gcc44's build time
shortened by the adoption of the --disable-libjava-multilib patch...

​http://trac.macports.org/attachment/ticket/21341/gcc44-disable-libjava.diff

[howarth@…]

Oh, I didn't realize this proposal was to build pymol against the gcc and g++
from gcc43/gcc44. I doubt this is really going to gain any particular performance
compared to using Apple's gcc-4.2.

[adfernandes (Andrew Fernandes)]

Well, personally, I'm all for using the lastest-and-greatest compiler... except when doing so breaks my codebase or forces me to recompile a zillion dependencies. A forced upgrade on boost, qt4, and kde4 will generate enough heat to keep Moscow warm all winter! :-)

But... choice in compiler is one of the features [sic] of MacPorts. I'm not a core developer, just a heavy user, and really don't want to get into (what I suspect) is a religious war. Sometimes I feel like I have spent 1/2 my life waiting for Gentoo to recompile my whole distro... and then the other 1/2 is waiting for Ubuntu or Fedora to update their packages because I need a build-option that they didn't include... :-)

BTW - my default compiler (10.5.8) is still 4.0; I suspect you're on SL if your default compiler is 4.2. There are definitely optimizer changes between those two.

Anyway - since you've taken over the port completely, I need your approval to commit. So - three questions:

1. Can I commit the patch, so as per current MacPorts tao people can select their compiler?
2. Do you want me to add openmaintainer to the port so that you don't need to be bothered with trivial updates? MacPorts policy allows commits without maintainer approval for trivial changes only; big changes require maintainer approval still.
3. Are you adding the [[BR]] tags to the trac entries on purpose? I'd request you not do that; it makes the email summaries really hard to read!

Thanks, -Andrew.

[howarth@…]

Andrew,

I wasn't adding the BR's in the past for my tickets and I noticed that these were being added

later so I assumed I should have them. Again, I really don't see the purpose of adding gcc43/gcc44 variants. You really aren't going to gain a major speed boost. A far more useful change would be to compile the python scripts into byte code (which I am looking at now). This may be why the configure build felt faster as it may have been compiling them automatically.

[adfernandes (Andrew Fernandes)]

I'm not worried about a speed boost; I'm building native code extensions as part of a much larger project; having compiler options ensures that I can keep one tool-chain consistent for all my research projects.

Loading different copies of libstdc++ into the same process is usually fine as long as everyone is careful about visibility, ctors and dtors, and all that. Unfortunately, that ain't often the case, so I try to keep everything consistent because debugging shared-lib problems is a great waste of time. I've done it, and I never want to do it again.

Anyhow... is there any reason not to allow different compiler variants? (a) For good or evil, that's the way MacPorts is set up, and (b) I need them - for me, the default compiler is 4.0 and I can't integrate it cleanly into my other projects.

I appreciate that in an ideal world we'd all use the same compiler and be happy, but that just ain't so. I require the gcc43 variant, it was trivial to add the gcc44 variant if anyone wants it, and that's that. The change doesn't affect anyone who doesn't want it, and the default compiler will be used.

Thanks!

[howarth@…]

So you are saying the problem is that the default compiler is gcc-4.0 on Leopard, right? If that is the problem (and if 10.4 is the oldest distribution MacPorts currently supports) why not just set CC to gcc-4.2 and CCX to g++-4.2 instead of creating FSF gcc variants? This would actually make the build more uniform across Leopard and Snow Leopard because both would use the 4.2.1 compilers.

[adfernandes (Andrew Fernandes)]

Jack - I appreciate your comment about setting CC to gcc-4.2, etc... but that doesn't address either my specific needs, nor the subject of this ticket.

MacPorts policy is to accept Portfile patches that allow people to customize their builds they way they want or need to. If someone wants to write a patch for it, and that patch doesn't interfere with anyone else and satisfies a possible wider need, then it is generally accepted.

I ask again - this is a trivial patch that won't adversely affect anyone and can be beneficial/necessary for some (namely me!) - can I please commit?

[adfernandes (Andrew Fernandes)]

Incidentally, MacPorts explicit policy is to depend and link, as much as possible, on the MacPorts dist itself, which is why the FSF compilers are used instead of Apple's. Also, I require gcc43 and (soon) gcc44 which are not apple-standard.

[howarth@…]

If you run this past the Project Managers and they are okay with it, I don't object.

[blb@…]

Note that the most prevalent reason ports depend on gcc* is to get the fortran compiler, there may be a few that use it for gcj; otherwise, the vast majority should build fine with the default for a given system. There are a few that otherwise use a gcc* port instead of Xcode's but I'm pretty sure they have a very good reason for doing so (see the R port​, atlas​, and gsl​ for a few).

[adfernandes (Andrew Fernandes)]

Replying to howarth@…:

If you run this past the Project Managers and they are okay with it, I don't object.

Bryan - sorry to bug you, but since you're a project manager and have already commented, could you please weigh in here? howarth wants an okay by a PM before commit.

This whole thread is about whether or not gcc43 and gcc44 variants are "okay" to provide, or if it's better to provide fewer options and variants.

The diff is clean and tested, and should not affect anyone not wanting it. I can state quite categorically that using gcc43 is required for my build projects.

Sorry... This thread has gone on waaaay too long for a simple patch... :-)

[ryandesign (Ryan Carsten Schmidt)]

Replying to adfernandes@…:

Loading different copies of libstdc++ into the same process is usually fine as long as everyone is careful about visibility, ctors and dtors, and all that. Unfortunately, that ain't often the case, so I try to keep everything consistent because debugging shared-lib problems is a great waste of time. I've done it, and I never want to do it again.

This sounds like a good reason to allow this change; I think this is also where #20103 is going. I've attached​ a revised patch that's a bit simpler.

[ryandesign (Ryan Carsten Schmidt)]

I replaced my patch with a revised one: depends_build should have been depends_lib, since we are linking with the relevant gcc port's libstdc++.

[adfernandes (Andrew Fernandes)]

Replying to ryandesign@…:

I replaced my patch with a revised one: depends_build should have been depends_lib, since we are linking with the relevant gcc port's libstdc++.

Thanks, Ryan. I had to modify your patch for the CC and CXX settings, though, because the Makefile does not honour the environment variables. I did change the compiler to depends_lib and the put the build.args into the pre-build stage.

Revised Portfile.2.diff​ attached. (Forgot to check "replace with same name"!)

[adfernandes (Andrew Fernandes)]

Committed in r60187. Approved by maintainer and Sr. Proj. Manager.

[adfernandes (Andrew Fernandes)]

Almost forgot - using ryandesign's gcc-guidelines written in response to this ticket.