What is the problem with using the shared spec ?

[adrienbernede]

https://github.com/LLNL/RAJA/blob/06853731c6deaf1b301b419f1d357c6e7e61a207/.gitlab/jobs/dane.yml#L20

Umpire requires a gcc-toolchain to be associated with the clang compilers.
LC magic wrapper also adds the gcc toolchain to clang/14.0.6-magic (module).

Is the clang-14-gcc-11 spack toolchain causing an error ?

[rhornung67]

A few comments here. First, the name of the shared job should include the gcc toolchain version so it's clear what is being used. Second, for RAJA we try to not use the LC wrappers if we can avoid them since they tend to hide compiler flags, etc. Neither the RAJA spec that overrides or the clang-14-gcc-11 script use an LC magic module as far as I can tell. Third, if Umpire requires a a gcc toolchain, it seems like a project-specific requirement and should not be a shared job? Fourth, if a gcc toolchain is required, we should stick to the system default (10.3.1) or the version that our users are using (13.3.1).

[adrienbernede]

Thanks for the details:

1. Agreed.
2. We don't use the wrappers unless we have too, that's the policy we stick to. However, in the large combinatory of toolchains we could create, lc wrappers can provide hints regarding what is usually used together.
3. It is project specific, but if I set clang 14.0.6 "naked" as a shared spec, I imply that it has been vetted with all our projects, but Umpire requires clang 14.0.6 with gcc toolchain... I can't add this locally to a project when building the radiuss stack. That's why I was suggesting clang-14-gcc as a shared toolchain, this one should be able to build any project, shouldn't it ?
4. When optimizing for dane architecture, gcc 11 is the minimum required. That’s why I updated it. If 13 is preferred, I can make that happen.