Request for comments: mpi and using multiple compilers

[Sean Farley]

dstrubbe at gmail.com writes:

>> Ah, that's something I tried to do at first as well. It's not possible
>> since it would lead to non-unique builds. For example, let's assume
>> arpack has a known problem with gcc46 and an unknown bug with
>> gcc45. In the arpack portfile, we'll put an error if +mpich is selected
>> when it was built with +gcc46. Now, 'port install arpack +mpich' would
>> have a very, very confusing error to solve if mpich was built with
>> +gcc45. Having the compiler in the variant makes a very clear
>> representation of what's going on.
>>
>>
> Not sure what you mean by this. It is "possible" in the sense that that is
> the current state of the arpack port and it is working. The previous state
> was, if you built arpack +mpich +gcc45, gcc45 would be used for the serial
> part, and mpich would be used for the parallel part of the code, regardless
> of what variant mpich had been built with. If you have a problem with
> arpack +mpich, I would ask as first question, what variant of mpich did you
> have? And then that would give the information needed to diagnose a problem
> with gcc45. I agree that this is "non-unique" but doesn't seem any more so
> than the fact that it may matter which version of mpich you used, or
> whether you used +gforker or +tuned.

It's much easier to see the problem as follows:

David's machine,
-David installs 'port install mpich +gcc45'
-David installs 'port install arpack +mpich'

Sean's machine,
-Sean installs 'port install mpich +gfortran'
-Sean installs 'port install arpack +mpich'

We both have 'arpack @3.1.3+mpich' installed but they were built with
two very different compilers: mine with clang and yours with gcc45. If
we force the user to specify the compiler then we can use
require_active_variants to make sure everything is in line, e.g.

arpack +mpich +gfortran -> mpich+gfortran will be used
arpack +mpich +gcc45 -> mpich+gcc45 will be used

And this ensures that the same compiler is used on all machines with the
same variants.

>> > On the other hand, sometimes it is necessary to enforce the same Fortran
>> > compiler used for MPI and for some dependency (when they use Fortran
>> > modules).
>>
>> s/sometimes/always/
>>
>> Anything else is inviting insanity.
>
> That seems a bit strong to me. If there are not Fortran modules used (.mod
> files), I don't see why it should matter. I have mixed and matched atlas,
> fftw, blacs, scalapack etc. between gfortran, g95, sunf90, etc. on linux
> quite a bit and not had any trouble.

I only mean enforcing the same compiler if the same variants are given
as I showed above.

>> > I am working on adding MPI support to the octopus port, and wrote
>> > the following Portfile code to handle such a dependency. Perhaps you can
>> > include something like this in MPI portgroup (and use your more extensive
>> > list of Fortran compilers available).
>>
>> This code just enforces the fortran variant of openmpi, correct? If so,
>> then I already enforce this through the require_active_variants block.
>>
> I am not sure whether what you have is the same idea or not. Where does
> your port group get "fortran_variant_name" from?

https://bitbucket.org/seanfarley/scienceports/src/default/_resources/port1.0/group/multiplecompilers-1.0.tcl#cl-297

It just simply loops through all the fortran variants (gccXY, gfortran,
and g95) and returns the one that is set or the empty string if none are set.