ambivalence about fortran (was Re: numpy & non-Apple gcc?)

[Ryan Schmidt]

On Sep 20, 2010, at 13:34, Takeshi Enomoto wrote:

> A few years ago sci port maintainers agreed to use gcc43 (now gcc44)
> as defaut.
> I prefer g95 but I accepted it since gfortran is a majority
> has more features (cray pointers, OpenMP) and has become as reliable as g95.
> 
> There is a drawback.
> It takes hours to build gcc4x to obtain gfortran.
> g95 requires less since it only builds c and fortran.
> Once gcc4x is installed it keeps rebuilding upon revision or version updates.

It doesn't rebuild itself, of course; it presents itself to the user in "port outdated" whenever it needs to be rebuilt, and the user rebuilds it using "sudo port upgrade gcc4x" or "sudo port upgrade outdated". But this is true of any port.


> gcc4x could be built quickly if fortran, java, and objc were variants

They can't be variants, because ports can't depend on variants of another port. The main reason why other ports depend on gcc4x ports is because they need fortran or java; it wouldn't make sense for a user to build a hypothetical gcc4x without the fortran and java variants, only to discover they need to rebuild it with the fortran variant to build this one port, only to discover later they need to rebuild it again with the java variant to build this other port.

n.b.: the gcc46 port does currently have java and fortran variants and does not include them by default. This is because gcc46 is still in development, and according to the maintainer, the java and fortran parts frequently break during development, and the maintainer does not wish to hold up testing of the core part of the port in these cases. This also enables the port to build quicker which is important to maintain maintainer sanity since during development new releases are made frequently. Once the port settles down to a stable version, these variants get removed and java and fortran always get built, for reasons as above.

> or they were separate ports.

Separate ports, perhaps. I'm not certain if the gcc4x build process provides the necessary level of granularity for splitting the port up like this, but if it does, that would be useful.


> I need fortran at work and I like it but it is a problem for sci apps in MacPorts.
> It is better to avoid fortran as a default if possible when writing a port.
> Recently I try to make fortran as variant
> if fortran is required to build a fortran interface (eg. plplot, grib_api).
> 
> ATLAS also needs a long time.
> I am asking the maintainer of octave to add no_atlas variant.
> <http://trac.macports.org/ticket/21797>
> It has been a reasonable choice to use atlas
> since there is a problem linking to some functions in Apple's accelerate.
> This was especially true with g95.
> I came up with a solution posted in the url above.