Use a common default variant for a recent gcc port in scientific packages

[alakazam@…]

I was discussing with the maintainer of the Arpack port (mmoll) by mail recently the fact that several (octave, arpack) scientific related ports depend on different gcc4X ports by default, and do not share common variants. This is in particular significant for ports that have cross dependencies and/or use fortran.

For instance, octave depends on g95, and has 2 variants : gcc42 and gcc43. Arpack depends on gcc42 and also has variants for g95 and gcc43. py25-scipy depends on gcc43 and has variants for gcc42 and gcc44, etc.

Marc suggested that we switch to gcc43 as a default variant for both octave and arpack, and I think we should extend this to all scientific related ports. Indeed, the initial issue arose when I tried compiling octave-arpack (depends on both octave and arpack), since two (very large) compiler packages where getting pulled and compiled.

I'd like some feedback on this issue from maintainers of scientific related packages, I've tried to CC most of those I could think of. Thanks !

mww (maintainer for the gcc ports), what's your take on the best gcc compiler to use (gcc42, gcc43, gcc44) ?

[mf2k (Frank Schima)]

Cc Me!

[skymoo (Adam Mercer)]

This would greatly simplify port maintenance, fewer variants to test, so I am all for this. There are other ports that have multiple compiler variants, fftw-3 for example:

[ram@cizin ~]$ port variants fftw-3
fftw-3 has the variants:
        universal: Build for multiple architectures
        i386: Platform variant, do not select manually
        powerpc: Platform variant, do not select manually
        gcc42: create Fortran wrappers using gcc42
        gcc43: create Fortran wrappers using gcc43
        gcc44: create Fortran wrappers using gcc44
        g95: create Fortran wrappers using f95
[ram@cizin ~]$

So having a single compiler variant would greatly simplify things.

I agree that gcc43 is probably the best choice at the moment.

[mww@…]

Currently I'd favor 4.3 over 4.4 in terms of bugginess, but not by far -- I'd expect 4.4.1 to be a good release (of the 4.4 line). 4.4 has of course the edge of being newer and therefore it will be supported longer than 4.3...

Long story short: If you can live with minor (!) problems till 4.4.1, I'd recommned going for that version. If you want stability right now, take 4.3.

[tenomoto (Takeshi Enomoto)]

One of the reasons I migrated to MacPorts from the other packaging system is that there are not much pushy rules and it is up to the maintainer how to design the default and variants. I am OK with using suggested gcc43 as the default variant since it simplifies maintenance. However, I'd prefer to make it as a recommendation rather than a strict rule, which should be usually respected unless there are some reasonable motivations to choose a package other than gcc43.

[alakazam@…]

I'm all for having reasonnable exceptions, but I think we can agree that the current situation clearly isn't about following a rule with a couple of exceptions.

And to clarify my initial post, I don't think personally that we should have only one variant, only that all ports that can use the same compiler do so by default. What variants would you suggest we keep ? For your ports for instance, what would be your choice of a default variant, and why ? This is clearly not about being pushy, but rather about user convenience :)

[tenomoto (Takeshi Enomoto)]

OK. I will make gcc43 the default variant and make g95 a variant, where possible. Currently gnudatalanguage, libnc-dap, plplot are already so. I need to update gcc42 to gcc43 fo adaptor. I have to swap roles between gcc43 and g95 for fgsl. I need to add gcc43 variant for udunits. Better to rename gfortran to gcc43 in hdf4. Here is an exception: vis5d+ fails to build with gcc43. I will give it another try. Please allow me some time to complete this.

[mamoll (Mark Moll)]

gcc43 is now also the default variant in ARPACK (see r53223). I also added a gcc44 variant.

It may not be obvious for the end user that it's easy to choose a preferred Fortran compiler in ${prefix}/etc/macports/variants.conf.

[tenomoto (Takeshi Enomoto)]

Replying to takeshi@…:

OK. I will make gcc43 the default variant and make g95 a variant, where possible.

I tried to use gcc43 (gfortran) as suggested but not completely successful. We do need g95 :-).

I need to update gcc42 to gcc43 fo adaptor. Better to rename gfortran to gcc43 in hdf4.

Done.

I have to swap roles between gcc43 and g95 for fgsl.

Not successful since gfortran does not support complex(c_double).

I need to add gcc43 variant for udunits.

udunits does not seem to require a fortran compiler at build time. gfortran does not work since it seem to have a problem with preprocessor (-traditional-cpp).

Here is an exception: vis5d+ fails to build with gcc43.

I left as it is.

[jameskyle@…]

Cc Me!

[jameskyle@…]

I've been updating the atlas port. It currently uses gcc43 as a default. I'll change over my other ports as well.

[alakazam@…]

I've updated the octave port in r54116 to use gcc43 as its default fortran compiler variant.

[adfernandes (Andrew Fernandes)]

Cc Me!

[skymoo (Adam Mercer)]

is it time to bump to gcc44 due to ATLAS?

[jmroot (Joshua Root)]

Switched to gcc44 in r68906.