Fortran recipe

Eric A. Borisch eborisch at macports.org
Thu Aug 29 09:03:46 PDT 2013


On Wed, Aug 28, 2013 at 9:14 PM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
>
> On Aug 28, 2013, at 18:06, Eric A. Borisch <eborisch at ieee.org> wrote:
>> Because when _I_ install mpich +gcc47 and then call mpicc/mpicxx, I want to get gcc47 (c/c++) behind it. Perhaps I'm doing a hybrid model with OpenMP and can't use clang.
>
> Hmm... but isn't mpicc and mpicxx a wrapper?  Why do you need to make that decision at build time?  Can't you let the user decide what C++ compiler mpicxx uses at runtime?

Yes, it is a wrapper, but there are also the compiled libraries that
actually supply the MPI functions. Yes, you can pass '-cc=XX'  or use
MPICH_CC, but the first reaction if something doesn't work right is to
"try reconfiguring MPICH with the new compiler and installing MPICH in
a separate location." (mpicc manpage) I take from that (and
experience) that the best practice is to avoid this (crow-baring of
compiler after the fact) approach unless it is unavoidable.

I've been considering splitting out the different variants into
(non-conflicting) subports; this would allow users to have different
mpicc/compiler combinations installed at the same time. Perhaps this
is also a solution to the problem here; the default / depended upon
(mpich) based on <MP default C/C++>/gfortran and the separate versions
(mpich_gcc44, mpich_clang33) being installed for outside-of-MP-scope
development for those who want them.

> I think the only time it would use llvm-gcc is on Xcode 4.0 and 4.1, which aren't supported configurations.  I think we officially just support 3.2.6 on SL, 4.2 on SL, and 4.6 on Lion/ML.  That means that the compilers we really care about are gcc-4.2 and clang.



More information about the macports-dev mailing list