Ports depending on mpich2: move to mpich

[Ryan Schmidt]

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.

>> 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. Why should we create another port for gfortran when we already have the gcc4x ports that do that? 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?

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

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.