Request for comments: mpi and using multiple compilers
sean at macports.org
Wed Jul 24 15:16:29 PDT 2013
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 installs 'port install mpich +gcc45'
-David installs 'port install arpack +mpich'
-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
>> > 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).
>> 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?
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.
More information about the macports-dev