Possible mpich changes / resolution [Was re: Fortran recipe]

[Eric A. Borisch]

> I think it comes down to "I'm installing X (from MP) so I need this
> thing I've never met called MPICH that is required" or "I'm installing
> MPICH so I can write an MPI program, and I want to use *cc because of
> Z." Perhaps the best way to serve both ends is to create sub-ports as
> I mentioned above.

I've put (in a separate branch [1]) changes in place to provide
mpich-default (which creates mpicc-mp, mpicxx-mp, and mpifNN-mp by
default) as well as a number of mpich-COMPILER ports to be installed
side-by-side, along with a mpich_select port to facilitate changing
what mpicc/mpicxx/mpifNN point to for the user. I would (assuming
people are OK with this approach) have ports that depend on mpich
(which itself is now a stub and depends on mpich-default) now use
MPICC=${prefix}/bin/mpicc-mp (or whatever is required for the
particular package) and depend on path:bin/mpicc-mp:mpich (might be
satisfied by mpich-devel-default) to insulate packages from the
current 'port select --set mpich mpich-XXX' setting. All of the
flavors use mpich-default's headers (and therefore depend on
mpich-default).

The mpich-default package builds just like (or at least is intended
to) the current mpich (system default CC/CXX; variant requested
fortran (gcc48 by default)) using the "fortran recipe." The other
mpich-COMPILER flavors are intended for users where mpich is the
endpoint of MP support, and the tools created are being used for
"external" work. These wrap the requested CC/CXX in addition to
fortran (depending on variant; using the recipe for non-gccNN ports,
and the matching gfortan for the gccNN ones.)

There is also a set of conflicting mpich-devel packages set up in the same way.

Let me know what you think / if that seems reasonable and I'll make
the changes (in the branch) to ports depending on mpich and then merge
everything at once back into trunk.

Thanks,
 Eric
[1] http://trac.macports.org/changeset/110432