On Mon, Mar 25, 2013 at 12:16 PM, Sean Farley <s...@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? 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. - Eric -- Eric A. Borisch
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
