How to move on with upgrade to v0.21.1

[jonasjucker]

How to move on with upgrade to v0.21.1

[jonasjucker]

@dominichofer No it is not, in #958 you still run into the issue that xpmem is concretized with %gcc, altough in V6 it is concretized with %nvhpc. And since the conflict is in v0.21.1 no way the concretizer will concretize to %nvhpc.

I put 1d7a27a into
branch dev_v0.21.1 directly and subsequently ICON worked with V6 and v0.21.1.

See these tests:
#909 (comment)
I could simply reintroduce it again and we are fine.

Is it clearer now?

[jonasjucker]

@dominichofer came up with a workaround for the concretizer in #961.

spack-c2sm main can now be updated to spack v0.21.1, since ICON can still be built with V6.

[bcumming]

To test building the MCH software stack using Spack v0.21, I would recommend using a new version of the MCH stack that has been built using Spack v0.21.

The v6 stack is built using v0.19, and a custom version of stackinator that had v0.19 support back-ported.
But we could upgrade to v0.21.1 and use mainline stackinator.

All testing should be done using the uenv tools to mount the image dynamically at /user-environment, instead of using a permanent mount point like /mch-environmengt/v6. This allows us to iterate more quickly.

[dominichofer]

By doing so Icon builds fine with V6 and v0.21.1 on Balfrin

Is it this PR? #958

[jonasjucker]

Actually 1d7a27a
simply deactivates the conflict, that was not present in v0.19.x:

# All compilers except for gcc are in conflict with +kernel-module:
requires("%gcc", when="+kernel-module", msg="Linux kernel module must be compiled with gcc")

to

# All compilers except for gcc are in conflict with +kernel-module:
#requires("%gcc", when="+kernel-module", msg="Linux kernel module must be compiled with gcc")

I have to do this by copying the package into our local repos to overwrite the defaults.

[jonasjucker]

solved by #909