Fix: Remove serialbox as permanent dep of ICON

[jonasjucker]

Serialbox has been a dependency of ICON even if serialization=none.

This was caused by the following lines that enforce same compilers for serialbox as for ICON:

    for x in serialization_values:
        depends_on('serialbox+fortran', when='serialization={0}'.format(x))
        # WORKAROUND: A build and link dependency should imply that the same compiler is used. This enforces it.
        depends_on('serialbox %nvhpc', when='%nvhpc')
        depends_on('serialbox %gcc', when='%gcc')

The two last lines falsely added serialbox as a dep, no matter the values the serialbox variant had.

The PR reorganises these lines to not add serialbox as a dep to ICON in case of serialization=none

[jonasjucker]

launch jenkins

[github-actions]

PR Preview Action v1.4.8
Preview removed because the pull request was closed.
2024-11-19 14:49 UTC

[jonasjucker]

spack spec icon%nvhpc serialization=create
==> Warning: Missing dependency not in database: zlib/suuzrnc needs gmake-5slczkk
==> Error: Spack concretizer internal error. Please submit a bug report and include the command, environment if applicable and the following error message.
    icon%nvhpc serialization=create is unsatisfiable

EDIT: seemed to be a cache problem

[jonasjucker]

Fix seems to work, correct compiler still chosen, whereas no dep to serialbox with serialization=none

• https://jenkins-mch.cscs.ch/job/Spack/job/spack_PR/1782/artifact/log/[email protected]_nvhpc_+coupling_serialization=create_+emvorado_+mpi_gpu=openacc+cuda_cuda_arch=80.log

• https://jenkins-mch.cscs.ch/job/Spack/job/spack_PR/1782/artifact/log/[email protected]_nvhpc.log

• https://jenkins-mch.cscs.ch/job/Spack/job/spack_PR/1782/artifact/log/[email protected]_gcc.log

[huppd]

Looks good to me. But is this still a workaround?

[jonasjucker]

Looks good to me. But is this still a workaround?

No this would be permanent. The package builds as it should.

[huppd]

Looks good to me. But is this still a workaround?

No this would be permanent. The package builds as it should.

But would it make sense to remove or adapt the workaround comment?

[jonasjucker]

Ah now I get it.

Yes the workaround for the concretizer is still there.
It is needed, otherwise we might try to link a gcc serialbox with nvhpc icon

[huppd]

Ah now I get it.

Yes the workaround for the concretizer is still there. It is needed, otherwise we might try to link a gcc serialbox with nvhpc icon

OK, got it. thanks for the explanation.

[jonasjucker]

launch jenkins

[jonasjucker]

launch jenkins