On Sep 30, 2014, at 4:10 PM, Sean Farley wrote: > ------- > Fortran > ------- > > While the above matrix was relatively straight-forward to implement > there was one glaring problem: fortran. LLVM / clang does not provide > it. Wonderful.
What portion of ports that want mpi also need a fortran compiler? 95%? 5%? > This creates the scenario of: does the port want the full suite of, for > example, gcc (meaning both C and fortran) or just the fortran > compiler. And which of these two strategies does the mpi portgroup employ? > This led to the creation of the 'require_fortran' monstrosity. With the release of OS X 10.9 and its use of libc++ we seem to have found the use of gcc ports as values for configure.compiler untenable, giving rise to the fortran recipe which just sets the fortran compiler and leaves the C/C++/ObjC/ObjC++ compilers alone: https://trac.macports.org/wiki/PortfileRecipes#fortran I'm not sure if or how this relates to the require_fortran that you mentioned above. > ------------- > Complications > ------------- > > There are two complications with this implementation. The first is that > there is no knowledge of configure.compiler (used for blacklisting). I don't understand the situation in depth, but if mpi is requested, shouldn't we just inspect the value of configure.cc / configure.cxx / configure.obcj / configure.objcxx / configure.fc etc. (in a pre-configure block, to give a port time to change compiler.blacklist / compiler.whitelist / compiler.fallback), and replace them with their corresponding mpi wrappers? If a port needs a Fortran compiler then it would also need to provide gcc variants which would select only the fortran compiler, a la the fortran recipe. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
