mpich should have variant +gcc47 by default

[dstrubbe (David Strubbe)]

For ports such as arpack and netcdf-fortran which have a +mpich variant, which in turns needs mpif77, it would be helpful if mpich by default used a variant that provides a Fortran wrapper. Otherwise, listing this port as a dependency just leads to an unusable being installed that doesn't satisfy the dependency. +gcc47 seems the most popular among ports now. That is the one used for openmpi, for example. I have provided a patch adapted from the openmpi Portfile.

[eborisch (Eric A. Borisch)]

Making mpich +gcc47 by default introduces a large number of dependencies (to build gcc47) that aren't required if someone doesn't need Fortran. I'm hesitant to add this as a default variant; it seems it would be better suited to use active_variants in arpack and netcdf-fortran.

Other thoughts?

[eborisch (Eric A. Borisch)]

Dependencies for mpich with and without +gcc47:

[dstrubbe (David Strubbe)]

Thanks for the comment. I saw that openmpi used gcc47 as a default, so I thought by analogy it should be the same for mpich. Maybe you disagree with the choice made there. active_variants doesn't really solve the problem: if you do "install arpack +mpich" and do not already have mpich installed, then mpich will be installed, and without Fortran by default. Then active_variants in the arpack Portfile will tell you that though openmpi was installed as a dependency, it is not acceptable since it doesn't have a Fortran wrapper. That is the issue I am trying to solve, which would happen for any port that wants mpif77 or mpif90.

[eborisch (Eric A. Borisch)]

I believe, but I could be wrong, that active variants can be used to say if port X is installed it, must have variant C or D active. (Else error out with an informative message to user.) If X is not installed, then error out with informative message to user that X needs to be installed with C or D active.

It seems this would suffice for the problem you're describing.

[dstrubbe (David Strubbe)]

All that active_variants can do for the user here is explain why configure would fail for arpack (i.e. no mpif77). It cannot make the correct variant be installed in the first place. But, if mpich had +gcc47 as default, then the situation I describe above would end in a successful build, not an error message (however informative).

[eborisch (Eric A. Borisch)]

I guess I'm OK with an informative error message that asks the user to make a choice (gcc46? 47?) the first time they install. It doesn't seem like too much of a barrier if it helps make sure they are getting the right thing the first time (especially if they might be building a full tool chain in the process.)

There's another side to this discussion w.r.t. compilers without fortran support (clang/llvm). It's been suggested that we support something like clang[c/c++] with gccXX supplied Fortran, for example. It hasn't been implemented yet, but it just underscores the range of ways one might want to configure an MPI install.

I like the default install to require as have as few dependencies as possible while still being functional. MPI is quite functional without Fortran (I use it daily in this fashion.)

[dstrubbe (David Strubbe)]

All right, I see.

Well, perhaps a Fortran MPI sub-port or stub port could be made that would allow the mixed installation you mention, as well as making sure that mpif77 is installed when needed as a dependency.

[cooljeanius (Eric Gallager)]

Cc Me!

[seanfarley (Sean Farley)]

Replying to dstrubbe@…:

All right, I see.

Well, perhaps a Fortran MPI sub-port or stub port could be made that would allow the mixed installation you mention, as well as making sure that mpif77 is installed when needed as a dependency.

This thread is exactly the problem I've been trying to solve over the last year or so, sporadically. The issue boils down to the fact that the clang family of compilers doesn't have anything for fortran and that macports doesn't split up gcc into non-fortan subports. So, there are a few routes to take:

1) split up gcc into subports

This would be a lot of work because of the many ports that implicitly assume that gcc has a fortran compiler.

2) split up mpi ports into fortan subports

This would break the macports structure of compilers already in place. Also, this breaks mpi standards because fortran mpi wrappers need to exist.

3) add gfortran to the clang variant of the mpi ports

This would add gcc as a dependency to all the clang variants.

I was originally opposed to (3) but now think this is the most complete solution. I don't think we should provide any variant of mpi without fortran wrappers. eborisch, I see that you aren't in favor of adding more dependencies but do you have any other ideas?

[dstrubbe (David Strubbe)]

Replying to sean@…:

2) split up mpi ports into fortan subports

This would break the macports structure of compilers already in place. Also, this breaks mpi standards because fortran mpi wrappers need to exist.

What do you mean that MPI standards require Fortran MPI wrappers? Some MPI's seem to produce useless Fortran wrappers that just write an error message if compiled without Fortran. Not sure how that helps anything. For comparison, the openmpi port does not bother installing mpif77 or mpif90 if installed without Fortran support.

[seanfarley (Sean Farley)]

Replying to dstrubbe@…:

Replying to sean@…:

2) split up mpi ports into fortan subports

This would break the macports structure of compilers already in place. Also, this breaks mpi standards because fortran mpi wrappers need to exist.

What do you mean that MPI standards require Fortran MPI wrappers? Some MPI's seem to produce useless Fortran wrappers that just write an error message if compiled without Fortran. Not sure how that helps anything. For comparison, the openmpi port does not bother installing mpif77 or mpif90 if installed without Fortran support.

And there's a reason OpenMPI isn't recommend by scientific projects. Apple shipped a broken MPI with Leopard and that was inexcusable. For not very good reasons, Bill Gropp and others decided that MPI should wrap compilers (instead of just providing linking flags) therefore and package providing MPI needs to provide the C and Fortran wrappers. As a note, C++ MPI has been deprecated.

[dstrubbe (David Strubbe)]

Can you please explain more? Why would it matter if mpif77 is present or not to compile MPI C code?

[seanfarley (Sean Farley)]

Replying to dstrubbe@…:

Can you please explain more? Why would it matter if mpif77 is present or not to compile MPI C code?

MPI is a standard not a language. A lot of Fortran people got on the MPI forum and voted to have it in the standard. C++ didn't make it.

[eborisch (Eric A. Borisch)]

Duplicate. (Sort of.)

Tracking WIP portfile <humor> providing plenty of rope to users who want it </humor> here: 40375. It breaks out wrapper (compiler) flavors into subports and uses the "fortran recipe" to boot. A new mpich_select is also in progress (see same ticket) that symlinks mpicc and friends to the version you are in the mood for.