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