search

eth-cscs / stackinator

https://eth-cscs.github.io/stackinator/
BSD 3-Clause "New" or "Revised" License
19 stars 15 forks source link

Better support for multi-compiler environments. #188

Closed bcumming closed 5 months ago

bcumming commented 6 months ago

Recipe authors are not able to set a "default" compiler when using more than one compiler toolchain to build packages in an environment. As a result, the spec list for such environments can be messy because the author has to explicitly set the compiler for many packages to override the compiler chosen by the concretizer.

For example, the following sample that explicitly sets %gcc from the MCH recipe:

  - netcdf-fortran@4.5.4%nvhpc
  - hdf5@1.12.2%nvhpc +szip +hl +fortran +mpi
  - openblas@0.3.21%nvhpc
  - libfyaml@0.7.12%nvhpc
  # Explicitly concretise the packages below with gcc as they shouldn't be
  # built with nvhpc.
  - ca-certificates-mozilla%gcc
  - jasper%gcc
  - libaec%gcc
  - libiconv%gcc

This PR makes the first compiler in the toolchain the default, and only overrides that choice for specs that explicitly specify the second compiler. For example, the following compiler settings would build with the gcc toolchain by default:

  compiler:
    - toolchain: gcc
      spec: gcc
    - toolchain: llvm
      spec: nvhpc
simonpintarelli commented 6 months ago

the gcc first policy is also applied to cray-mpich. Should it be made automatic? Any environment using nvhpc must most likely use cray-mpich%nvhpc. Or it should be enforced that in mpi.spec there is always either %gcc or %nvhpc.

bcumming commented 6 months ago

the gcc first policy is also applied to cray-mpich. Should it be made automatic? Any environment using nvhpc must most likely use cray-mpich%nvhpc. Or it should be enforced that in mpi.spec there is always either %gcc or %nvhpc.

The compiler for cray-mpich can be explicitly provided in the mpi: field, like it is for the MCH recipe:

https://github.com/eth-cscs/alps-uenv/blob/main/recipes/wcp/icon/v1/gh200/environments.yaml#L9