Request for comments: mpi and using multiple compilers

[Eric A. Borisch]

On Thu, Jul 25, 2013 at 9:31 PM, Sean Farley <sean at macports.org> wrote:
>
> eborisch at macports.org writes:
>
>> On Thursday, July 25, 2013, Sean Farley wrote:
>>
>>>
>>> eborisch at ieee.org <javascript:;> writes:
>>>
>>> > On Thursday, July 25, 2013, Sean Farley wrote:
>>> >>
>>> >> But really, we're at the whim of what the macports community whats to do
>>> >> in this situation. Since my Ph.D is riding on getting a working mpi +
>>> >> fortran, I'd very much like to iron out these issues and get the ports
>>> >> chugging along!
>>> >>
>>> >
>>> > Does mpich +gccXX not get you to working fortran and MPI?
>>> >
>>> > I'll try to read through some of this thread later, but just looking for
>>> > clarification on that point.
>>>
>>> Again, the issue is when using libraries dependent on mpi and
>>> exacerbated on dependents of those dependents. This usually results in
>>> breakage with the inability to specify which compiler to use in the n-th
>>> dependent.
>>>
>>
>> Again, I haven't scoured the whole thread, but would making sub-ports
>> rather than variants for the different compilers help? The
>> dependent's +gcc44+mpich could require the mpich-gcc44 package, for example.
>
> Not really. It just changes the name to the same problem.

Except for the fact that you can *depend* on the package (user gets
warnings if they try to install it) but MP will happily let the user
change the variants without warning to the (active) dependents of that
package. I personally swap back and forth between variants of mpich
when I'm testing my own MPI code (why, oh why, doesn't clang have
OpenMP support yet?) Hopefully rev-upgrade will catch that something
has (potentially) gone south, but it won't likely be able to rebuild
things back to their initial state without some hand-holding.

We could setup the different packages to avoid naming conflicts (much
like gcc44, gcc45) so multiple versions could be installed
side-by-side. An mpich_select could even be put together to redirect
mpicc -> mpicc-gccNN.

I'm not saying it's necessarily the right idea, I'm just throwing it out there.

 - Eric
-- 
Eric A. Borisch