Ports depending on mpich2: move to mpich

[Sean Farley]

On Sat, Jan 26, 2013 at 8:15 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jan 25, 2013, at 19:31, Sean Farley wrote:
>> On Fri, Jan 25, 2013 at 7:22 PM, Eric A. Borisch wrote:
>>> Simultaneous openmpi and mpich is (if I recall) down to some man page
>>> conflicts. (Openmpi is renaming their bins, but not the associated mans.)
>>
>> That's right; what would be the resolution?
>
> We could rename the manpages ourselves.
>
>> Also, why does the openmpi rename their binaries? The standard, I believe, calls for
>> mpi{cc,cxx,fc,f77} (maybe it's f90, but whatever). I think all mpi
>> ports should install mpi{cc,cxx,fc,f77} … but this would negate having
>> more than activate at the same time (this is fine by me and I already
>> have scripts to deal with the variants).
>
> MacPorts would love for as many ports to be simultaneously installable as possible, and that requires that they do not install same-named files into the same locations.

This could be accomplished much like the gcc4X ports:
mpicc-mp-mpich-3.0 (or something else uniquely identifying) with a
corresponding `port select mpi XYZ`.

>>> Re:fortran, how would you propose 'mpich +clang' (for example) address
>>> Fortran? I personally use mpich (cc/ccx) extensively without Fortran; should
>>> I be required to install a fortran compiler & wrapper I don't need? If
>>> installed with a +gcc variant (and therefore a fort compiler is present)
>>> mpich enables fortran.
>>
>> mpich +clang would, by default, install a binary version of gfortran
>> (for intel macs). This is what I have done for mac users at Argonne
>> with my scienceports repo,
>>
>> https://bitbucket.org/seanfarley/scienceports/src/tip/lang/gfortran?at=default
>>
>> So far, it's worked well and is a saner way of providing fortran since
>> most scientists will install the fortran version from
>> hpc.sourceforge.net.
>
> You mentioned this elsewhere recently (I thought it was a ticket but I can't find one) and I had meant to comment that I'm not comfortable with this.

It was a previous email:
https://lists.macosforge.org/pipermail/macports-dev/2013-January/021656.html

> Why should we create another port for gfortran when we already have the gcc4x ports that do that?

As I mentioned in the other thread, this is because there is no
fortran compiler coupled with clang. Having a designated port will
"close" the dependency graph uniquely so that there is no ambiguity
when wanting to use clang for C and <some gfortran version> for
fortran. If we were to solely rely on gcc4X then it would be
impossible to specify (easily) clang+fortran.

> Why should we single out a specific version to offer this way when we already offer all versions in the gcc4x ports? Why should this new port install a pre-built binary when MacPorts already builds and distributes its own binaries of the gcc4x ports?

Same as above: there is no unique closure of the dependency graph when
wanting clang for compiling C. The version doesn't matter as long as
it's above 4.3 (I just chose the latest stable).

> The way we've always handled this before is: if your port requires fortran, add gcc variants to let the user choose, and select the gcc45 variant by default:
>
> https://trac.macports.org/wiki/PortfileRecipes#gcc

This is the number one reason why scientists ditched MacPorts: no
basic gfortran. I don't want to use the entire gcc suite as the
default when wanting just fortran. These people will then install the
binary gfortran available from hpc.sourceforget.net and then cause a
huge amount of headache for everyone involved.

As you can see, fortran was the underlying reason I started
SciencePorts: https://bitbucket.org/seanfarley/scienceports/commits/all/tip/0

That initial commit was to try and tame the fortran dependency.

> One reason why we let the user choose which gcc4x port to use is that mixing and matching gcc versions caused hard-to-diagnose problems because they each had their own version of libstdcxx. Now that gcc47 and below all use libstdcxx 4.7 that's presumably no longer a problem, except for gcc48. Perhaps we should revisit whether providing multiple gcc4x variants is necessary anymore; perhaps we can instead just depend on the latest stable gcc4x and be done with it.

I think the latest stable gcc should be default and I would propose to
use a port group (which I've already written, actually; just needs to
be agreed upon and ironed out) for any port that 1) needs fortran
and/or 2) wants to offer different compiler variants. In fact, this
could make it easier to update macport compilers without needing to
release a new version of macports.

In summary, none of the solutions you provide solve the scenario: "I
want clang for C and <fortran compiler> for fortran." This also is a
problem for users of `port select <compiler> XYZ` that *just* want a
fortran compiler since the clang-3.X ports don't have one.

I think it would be much easier to have every compiler port (gcc4X,
clang-3.X) to have fortran defined. If the port doesn't have it, then
we could provide it with a standalone port. This would take a lot of
hacky code out of individual portfiles that need fortran (and hence
out of mpi-derived ports).