hpc gfortran

[Sean Farley]

Eric A. Borisch writes:

> On Mon, Mar 25, 2013 at 12:16 PM, Sean Farley <sean at macports.org> wrote:
>
>>
>> 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.
>>
>
> Is it worth it to split out gfortran? Is, for example, installing the
> current gcc47 port *that* much of an issue for those that require
> bin/gfortran-mp-4.7?
>
> If the answer is no, it's not much of an issue, and you just want the mpi
> ports to break-out fortran selection, shouldn't we just handle it in those
> use cases?

I would say it is worth it because currently there is no sane way to
specify a sole fortran compiler. I currently have many ports that I
haven't added to macports because they are all fortran packages and as
such, they expose the gap between using a c compiler with a fortran
compiler.

As for splitting out java, I can't say. I have no experience there.

> It would be nice to have 'configure compiler macports-gfortran-4.7' work to
> fill in just the configure.f* flags for this use case.
>
> If the desire is to really split it out, I would float the possibility
> having the gccNN port require the gfortranNN port. This would remove the
> requirement to update all of the ports currently using gccNN and expecting
> to get gfortranNN.

That's a good point.