Request for comments: mpi and using multiple compilers

[Sean Farley]

dstrubbe at mit.edu writes:

> On Sat, Jul 20, 2013 at 7:28 PM, Sean Farley <sean at macports.org> wrote:
>
>> Hi all,
>>
>> I'm looking for comments and feedback for two new port groups:
>> multiple compilers [1] and mpi [2]. My goal is to unify all the gcc4X
>> variants and mpich / openmpi variants scattered throughout the port
>> tree.
>>
>
> Sounds like a good idea to me.
>
>
>> $ port install netcdf +mpich +gfortran
>> --->  Computing dependencies for netcdf.
>> --->  Configuring netcdf
>> Error: org.macports.configure for port netcdf returned: mpich must be
>> installed with +gfortran.
>>
>
> The netcdf port does not use fortran, the fortran interface is in
> netcdf-fortran. So I don't understand what putting +gfortran here would do.

Yes, you're correct. I should have a way to blacklist variants which I
will do in my next round.

> I think in most cases that if you use MPI, then there is no need to specify
> the underlying compiler also (since compiling even non-MPI code in the
> package with mpich +gfortran is the same as just using gfortran). Recently,
> we sorted this out for the arpack port.

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.

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

> 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).
>
> set fortran unknown
> set fortrans { gcc42 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 g95 }
> foreach fc_name ${fortrans} {
>     if { [variant_isset ${fc_name}] } {
>         set fortran ${fc_name}
>     } elseif { [variant_isset openmpi] } {
>         if { [active_variants openmpi ${fc_name}] } { set fortran
> ${fc_name} }
>     } elseif { [variant_isset mpich] } {
>         if { [_portnameactive mpich] } {
>             if { [active_variants mpich ${fc_name}] } { set fortran
> ${fc_name} }
>         } elseif { [_portnameactive mpich-devel] } {
>             if { [active_variants mpich-devel ${fc_name}] } { set fortran
> ${fc_name} }
>         }
>     }
> }
>
> pre-fetch {
>     if { ${fortran} == "unknown" } {
>         if { [variant_isset openmpi] } {
>             ui_error "Variant +openmpi requires openmpi to have been built
> with Fortran support."
>             return -code error "Variant +openmpi requires openmpi to have
> been built with Fortran support."
>         } elseif { [variant_isset mpich] } {
>             ui_error "Variant +mpich requires mpich/mpich-devel to have
> been built with Fortran support."
>             return -code error "Variant +mpich requires mpich/mpich-devel
> to have been built with Fortran support."
>         } else {
>             ui_error "Internal error: cannot determine Fortran compiler."
>             return -code error "Internal error: cannot determine Fortran
> compiler."
>         }
>     }
>     ui_msg "Fortran compiler is ${fortran}."
> }
>
> require_active_variants libxc ${fortran}

This code just enforces the fortran variant of openmpi, correct? If so,
then I already enforce this through the require_active_variants block.

>> https://bitbucket.org/seanfarley/scienceports/src/2832e9d9716e178f20b5ab0eb563f40d7fcce730/_resources/port1.0/group/mpi-1.0.tcl?at=default
>>
>>
> Looks like you should call openmpi-devel "OpenMPI-devel" not "OpenMPI" in
> the description, by analogy to MPICH.

Oops, copy + paste error. Thanks for pointing it out.