hpc gfortran

[Joshua Root]

On 2013-3-25 03:45 , Sean Farley wrote:
> I know I've brought this up before but I'd like to get some resolution
> on the following issues,
> 
> 1) HPC gfortran
> 
> Due to a lack of a standalone gfortran compiler, most users that need it
> seem to go to hpc.sourceforge.net and download the version there. This
> is all kinds of unwanted behavior that could be fixed with a standalone
> gfortran port.
> 
> 2) clang + fortran
> 
> Clang is the only compiler suite so far that has no fortran
> component. There is dragonegg but that also has its own c compiler. The
> de facto standard for a (free) fortran compiler seems to have fallen to
> gfortran. So, the issue here that I see is when a port wants the clang
> compiler + a fortran compiler. Currently, in macports it is up to the
> portfile author to decide to use the default c compiler or to use gcc4X
> (as opposed to letting the user decide).
> 
> 3) compiler wrappers
> 
> So far, this only applies to MPI but it could also apply to packages
> like TAU [1]. When a package depends on MPI, the standard implies there
> will be at least mpicc and mpifc. Again, the issue here could be solved
> with a standalone gfortran port.
> 
> Having a standalone gfortran compiler would be able to solve (1-3)
> but I haven't gotten good feedback on that so far. So, I'm asking the
> macports devs for some ways to solve the above issues that everyone
> would be comfortable with.

I don't think anyone would object to splitting gfortran (and gcj) out in
subports of the various gccXY and dragonegg ports. It's just that so
far, nobody did the work.

- Josh