You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I've been checking the shape of mpich and openmpi packages in Nixpkgs, and noticed that the Kitware's FindMPI.cmake attempts (at least when it doesn't locate mpiexec, which unless I'm wrong is only useful when building for the native platform) discovering the MPI implementations using pkg-config under the target names of mpi-c, mpi-cxx, and mpi-fort, neither of which are generated by mpich's (or openmpi's, probably not by other implementations either): https://gitlab.kitware.com/cmake/cmake/-/blob/2744f14db1e87f4b7f6eb6f30f7c84ea52ce4a7a/Modules/FindMPI.cmake#L1584-1592
I didn't find any mentions of these pkg-config files on discuss.cmake.org or on https://gitlab.kitware.com/cmake/cmake, and I haven't reached out there myself yet, so I'm not entirely sure what use-case that part of FindMPI is serving. We could just generate these files ourselves in Nixpkgs, effectively implementing an "alternatives" mechanism. However I also see that mpich generates a single merged .pc file with custom variables which could have also been addressed using the same layout expected by cmake:
❯ cat /nix/store/24sv27w3j1j3p7lxyh689bzbhmixxf35-mpich-4.1.2/lib/pkgconfig/mpich.pc
...
Cflags: -I${includedir}
...
# pkg-config does not understand Cxxflags, etc. So we allow users to
# query them using the --variable option
cxxflags= -I${includedir}
fflags=-fallow-argument-mismatch -I${includedir}
fcflags=-fallow-argument-mismatch -I${includedir}
To build up more context, openmpi appears to generate a layout similar to that expected by cmake, only with different names:
❯ ls /nix/store/nf8fqx39w8ib34hp24lrz48287xdbxd8-openmpi-4.1.6/lib/pkgconfig/
ompi-c.pc ompi-cxx.pc ompi-f77.pc ompi-f90.pc ompi-fort.pc ompi.pc orte.pc
I was wondering what is the mpich maintainers' opinion on how mpich should be consumed with pkg-config (and-or CMake), especially when writing mpi implementation-agnostic programs, and/or when doing cross-compilation? What do you think about the linked snippet from FindMPI.cmake in particular?
I guess we can generate mpich-c.pc, mpich-cxx.pc, and mpich-fort.pc. Then it is up to distribution to create links to mpi-c.pc, mpi-cxx.pc, and mpi-fort.pc.
Hi! I've been checking the shape of mpich and openmpi packages in Nixpkgs, and noticed that the Kitware's FindMPI.cmake attempts (at least when it doesn't locate
mpiexec
, which unless I'm wrong is only useful when building for the native platform) discovering the MPI implementations usingpkg-config
under the target names ofmpi-c
,mpi-cxx
, andmpi-fort
, neither of which are generated by mpich's (or openmpi's, probably not by other implementations either): https://gitlab.kitware.com/cmake/cmake/-/blob/2744f14db1e87f4b7f6eb6f30f7c84ea52ce4a7a/Modules/FindMPI.cmake#L1584-1592I didn't find any mentions of these pkg-config files on discuss.cmake.org or on https://gitlab.kitware.com/cmake/cmake, and I haven't reached out there myself yet, so I'm not entirely sure what use-case that part of FindMPI is serving. We could just generate these files ourselves in Nixpkgs, effectively implementing an "alternatives" mechanism. However I also see that mpich generates a single merged
.pc
file with custom variables which could have also been addressed using the same layout expected by cmake:To build up more context, openmpi appears to generate a layout similar to that expected by cmake, only with different names:
I was wondering what is the mpich maintainers' opinion on how mpich should be consumed with pkg-config (and-or CMake), especially when writing mpi implementation-agnostic programs, and/or when doing cross-compilation? What do you think about the linked snippet from
FindMPI.cmake
in particular?Thanks!
EDIT: CC https://gitlab.kitware.com/cmake/cmake/-/issues/25529
The text was updated successfully, but these errors were encountered: