This is a proposal/discussion on how to improve the MPI packaging guidelines to simplify the spec files.

What we have so far

So far we have found a few tricks to simplify the script:

• set %global _vpath_builddir %{_vendor}-%{_target_os}-build${MPI_SUFFIX:-_serial} and use a for loop to go through the mpi variants. For example:

for mpi in '' mpich %{?with_openmpi:openmpi}; do
  if [ -n "$mpi" ]; then
    module load mpi/${mpi}-%{_arch}
    cmake_mpi_args=(
      "-DCMAKE_INSTALL_PREFIX:PATH=${MPI_HOME}"
      "-DCMAKE_INSTALL_LIBDIR:PATH=lib"
      "-DUSE_MPI:BOOL=ON"
    )
  else
    cmake_mpi_args=(
      "-DUSE_MPI:BOOL=OFF"
    )
  fi
  %cmake ${cmake_mpi_args[@]}
  %cmake_build
done

Some issues

• The issue with manually running module load instead of %_openmpi_load is that it misses on some specific environment's improvements, e.g. export PRTE_MCA_rmaps_default_mapping_policy=:oversubscribe. But these macros are static so we cannot easily incorporate them in the for loop above

What can be improved

• Maintain a common macro interface like %mpi_load which uses a shell if checks for loading specific %_openmpi_load, etc. This could be combined with the %global _vpath_builddir simplification
• Make a lua/python etc. script helpers like the %pyproject macros to make the module preparation more dynamic
• Templating the mpi package metadata as well. If the spec file is not mpi-backend dependent, i.e. the (Build)Requires for openmpi are the same for mpich
• Making the script more reusable for upstream. Let's say upstream wants to package with an additional intel mpi variant and use some automation with copr/packit etc. and have a synchronized upstream/downstream spec file. It would be helpful if this process is easily expandable to variable mpi backends. (Disregard the licensing issues and everything, maybe they are advanced enough to host their own copr cluster)

Tagging some people who participated in the previous issue @davidsch @ngompa @gotmax23 @james @rathann