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 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
