hpc gfortran

[Sean Farley]

Eric A. Borisch writes:

> On Sunday, March 24, 2013, Joshua Root wrote:
>
>> 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
>>
>
> I'm all for it. It's likely less of an issue for many now that the
> buildbots pull so much of the install/upgrade times down. I'm happy to
> update mpich to have separate fortranNN and gcc/clang/llvm selectors.

Great, thanks!

> Looking forward, should a gccNN require the matching gfortranNN?

Good question.