ompi
ompi copied to clipboard
open-mpi
Add generic MPI pkgconfig descriptors
cmake recently gained support to use pkgconfig to detect MPI options (see https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6537/diffs). This is useful e.g. when cross-compiling. Cross-compiling with OpenMPI fails regularly for me because mpicc etc. are binaries and cannot be executed.
This cmake patch looks for pkgconfig setups called mpi-c, mpi-cxx, and mpi-fort. It would be good if OpenMPI provided such configuration, in addition to the ompi-c.pc etc. that it already provides.
Here is my counter offer:
the CMake patch should be enhanced in order to also look for ompi-c.pc and friends.
I thought about this, and I think this wouldn't be scalable. This means that cmake would need to look for all possible MPI implementations, and it would fail if it encounters an unknown one.
All cmake configuration logic starts from known, semi-standardized files (e.g. mpicc). Adding pkgconfig/mpi-c.pc would continue this.
For now, there are two main MPI implementations: MPICH and Open MPI, and each have several derivatives.
So from a pragmatic point of view, this limits scalability to 2.
Note you can configure Open MPI with --enable-script-wrapper-compilers in order to generate scripts instead of binaries.
@eschnett Is that sufficient?
FWIW, I agree with @ggouaillardet: I don't think we want the files named the same across different MPI implementations. That will make potential binary package file conflicts (e.g., if Open MPI and MPICH RPMs both contain /same/path/to/mpi-c.pc, then they both can't be installed at the same time). Downstream OS distros may not care for that kind of solution.
The --enable-script-wrapper-compilers was very useful to know, but that is independent of the issue here. I am looking for a way to make finding MPI as easy as finding any other package, and pkgconfig seems to be a good way to go.
The packages already both contain a include/mpi.h, so the additional conflict didn't seem too problematic to me. If you disagree, then we can discuss with the cmake maintainers to look for the pkgconfig names of known MPI implementations.
That's a fair point about include/mpi.h; we've obviously mandated to have that filename. But it does pretty much nullify my argument about conflicting filenames in binary packages.
FWIW, @ggouaillardet is correct: there are a finite number of MPI implementations, and there really aren't any new mainstream ones coming any time soon.
Also FWIW, it looks like MPICH installs mpich.pc (not mpi-*.pc). I'm not sure at which MPI implementations https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6537/diffs was aimed...? Was it aimed at OS distros that setup "alternatives" for Open MPI and MPICH (i.e., sym linking Open MPI's / MPICH's pc files to mpi-*.pc?).
Even if it was aimed at "alternatives"-style mpi-*.pc files, I also note in the comments in mpich.pc that they do not install multiple pc files (i.e., one per language). Instead, they expect the user to use pkg-config's --variable option to get the options for other languages. Hence, cmake will need to do something different for MPICH's pc file vs. Open MPI's pc files.
Finally, given the long tail of Open MPI installs in use out in the real world (that use ompi-c.pc, etc.), you may well get both a quicker and more robust resolution by having the cmake maintainers search for ompi-*.pc and mpich.pc.
Related:
- https://github.com/pmodels/mpich/issues/6845#issuecomment-1857102395
- https://github.com/NixOS/nixpkgs/issues/274868
Openmpi's current layout maps somewhat directly onto FindMPI.cmake's expectations, and mpich is open to implementing the same pattern. Downstream distributions (Nixpkgs, Debian, hypothetically speaking something like Vcpkg too) could in principle take on the responsibility of exposing these files under the exact names expected by CMake. I think that wouldn't be too bad, although I'd prefer to see CMake work with ompi/mpich as is too.
EDIT: CC https://gitlab.kitware.com/cmake/cmake/-/issues/25529
