Ports depending on mpich2: move to mpich

Sean Farley sean at macports.org
Fri Jan 25 17:31:12 PST 2013


On Fri, Jan 25, 2013 at 7:22 PM, Eric A. Borisch <eborisch at macports.org> wrote:
> On Friday, January 25, 2013, Sean Farley wrote:
>>
>> On Fri, Jan 25, 2013 at 3:29 PM, Eric A. Borisch <eborisch at macports.org>
>> wrote:
>> > The MPICH project has named version 3 of the software as MPICH v3.0
>> > (rather
>> > than continuing on MPICH2 to become MPICH3.) The mpich[-devel] port has
>> > been
>> > moved (r100087) to this up-to-date version.
>> >
>> > At this time, I'm ready to move all ports that depend on MPICH2 to MPICH
>> > (v3), as well as to mark MPICH2 as replaced_by MPICH. (These two steps
>> > could
>> > be done separately -- suggestions on if this should be an atomic change,
>> > or
>> > two changes -- and in which order?)
>> >
>> > I have attached a patch that does just that, and have copied all
>> > portfile
>> > owners associated on the ticket https://trac.macports.org/ticket/37785
>> > with
>> > the diff attached.
>> >
>> > I plan to apply the patch next week unless there are concerns raised.
>>
>> Cleaning up the mpi ports is fantastic! Could we also use this time to
>> remove lammpi (it has long since died and been replaced by openmpi)?
>> The only issue I can remember is that the simultaneous installation of
>> openmpi and mpich is broken.
>>
>> Also, I still would like all mpi ports (mpich and openmpi … are there
>> any others still working?) to always have a fortran compiler, would it
>> be reasonable to talk about that here?
>
>
> 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? 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).

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

> I'm dead set not against it, but I suppose I need some convincing.

Understandable. One of my goals of scienceports was to never force the
user to compile a compiler (by default / if they didn't want to).
Scientists at the lab seem to be quick stubborn about these kinds of
things :-)


More information about the macports-dev mailing list