openmpi @1.6.4 +gcc45 non-standard names for executables

[dstrubbe (David Strubbe)]

The standard names for executables from OpenMPI are mpif90, mpif77, mpicc, mpirun, mpiexec. However, the ones provided by the openmpi port are all prefixed with "open", i.e. openmpif90 etc. I suggest this should be made clear somewhere in the port description, or alternately use the standard names (maybe the names were chosen to avoid conflict with mpich). I only discovered the actual names by reading through some tickets about this port. For example, the 'variants' output lists specifically the standard names, which are NOT the ones created by the port.

openmpi has the variants:
   g95: build mpif77 and mpif90 using g95
     * conflicts with gcc43 gcc44 gcc45 gcc46 gcc47
   gcc43: build mpif77 and mpif90 using gcc43
     * conflicts with g95 gcc44 gcc45 gcc46 gcc47
   gcc44: build mpif77 and mpif90 using gcc44
     * conflicts with g95 gcc43 gcc45 gcc46 gcc47
[+]gcc45: build mpif77 and mpif90 using gcc45
     * conflicts with g95 gcc43 gcc44 gcc46 gcc47
   gcc46: build mpif77 and mpif90 using gcc46
     * conflicts with g95 gcc43 gcc44 gcc45 gcc47
   gcc47: build mpif77 and mpif90 using gcc47
     * conflicts with g95 gcc43 gcc44 gcc45 gcc46
   threads: enable threads for MPI applications
   valgrind: enable valgrind support

I am using OSX 10.8.2 and Xcode 4.6.

[ryandesign (Ryan Carsten Schmidt)]

Yes I would imagine the names are changed to avoid conflicts. But it's been that way ever since the port was first added in r14861 over seven years ago. It does seem like the variant descriptions (which were added in r35330) should show the correct filenames. Note that you can always discover what files a port installs by using e.g. "port contents openmpi".

[dstrubbe (David Strubbe)]

Thanks for the note about "port contents", I hadn't realized that.

Actually I notice that mpich conflicts with openmpi so only one can be installed at a time, so it's not clear that the names need to be different for that. However, the port "lam" does not conflict with openmpi, so perhaps that is a better reason.

[seanfarley (Sean Farley)]

Replying to dstrubbe@…:

Thanks for the note about "port contents", I hadn't realized that.

Actually I notice that mpich conflicts with openmpi so only one can be installed at a time, so it's not clear that the names need to be different for that. However, the port "lam" does not conflict with openmpi, so perhaps that is a better reason.

No, there is no specific reason for it besides neglect. lammpi is decrepit and should be replaced_by openmpi. Ideally, we should have a 'port select mpi …' but that would probably involve switching the mpi ports to subports. Any thoughts from other devs on that?

[larryv (Lawrence Velázquez)]

Replying to sean@…:

No, there is no specific reason for it besides neglect. lammpi is decrepit and should be replaced_by openmpi. Ideally, we should have a 'port select mpi …' but that would probably involve switching the mpi ports to subports. Any thoughts from other devs on that?

There’s no need to make them subports. All the port select mechanism does is specify symlinks and the files in applicable ports that can be the targets. See clang and gcc, for instance.

[dstrubbe (David Strubbe)]

I have just attached a patch that would use the standard names of mpicc, mpif90, mpirun, etc. and would establish conflicts with the other mpi packages to prevent any name collisions. (mpich already lists openmpi as a conflict, so it seems logical that it should be mutual.)

[mf2k (Frank Schima)]

Since this changes the names of installed files, the revision needs to be increased by 1. In this case add the following line below the version.

revision    1

[dstrubbe (David Strubbe)]

Ok, updated the patch accordingly.

[dstrubbe (David Strubbe)]

I understand that the change I proposed to the installed wrappers names would necessitate wide-ranging changes to other ports for compatibility. Instead, I suggest simply making the variants identify the names of the wrappers they are building, and establish conflicts with mpich etc. Otherwise, installing openmpi when mpich is present gives:

Error: org.macports.activate for port openmpi returned: Image error: /opt/local/share/man/man1/mpicc.1.gz is being used by the active mpich port. Please deactivate this port first, or use 'port -f activate openmpi' to force the activation.

See new patch attached, Portfile-openmpi.diff2

[petrrr]

Replying to dstrubbe@…:

I have just attached a patch that would use the standard names of mpicc, mpif90, mpirun, etc. and would establish conflicts with the other mpi packages to prevent any name collisions. (mpich already lists openmpi as a conflict, so it seems logical that it should be mutual.)

I already had some thought on this issue recently, but discover this ticket only now. I find the port select mechanism cleaner. Maybe, resolving the conflict with mpich is feasible, so providing mpi_select could be the better choice.

[petrrr]

Cc Me!

[larryv (Lawrence Velázquez)]

Committed your second patch in r106993.