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

[Jeremy Huddleston Sequoia]

Hi Eric,

This sounds like a good approach.  It is actually quite similar to what I did for the same style of problem with the dragonegg ports, so I'm embarrassed I didn't think about suggesting this before =)

Thanks for coming up with a good solution that satisfies all the needs.  This is great progress.

--Jeremy

On Aug 30, 2013, at 20:55, Eric A. Borisch <eborisch at macports.org> wrote:


>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130830/7af920d8/attachment.p7s>