Closed penguian closed 2 months ago
Converted to draft while testing the oneapi
build, and while waiting for the pull request on UM_v7
to be resolved.
Testing the debug build with each of the following three variant syntaxes:
$ spack install um7 opt=debug@git.4-create-a-working-debug-build%intel
$ spack install um7@git.4-create-a-working-debug-build opt=debug%intel
$ spack install um7@git.4-create-a-working-debug-build%intel opt=debug
consistently fails with the following Spack internal error:
==> Error: Spack concretizer internal error. Please submit a bug report and include the command, environment if applicable and the following error message.
um7@git.4-create-a-working-debug-build=0-git.682%intel opt=debug is unsatisfiable, errors are:
internal_error("Reuse version weight used for build package")
internal_error("imposed hash without imposing all variant values")
internal_error("must choose a single version to satisfy version constraints")
internal_error("version weights must exist and be unique")
This appears to be caused by a known issue in Spack itself: https://github.com/spack/spack/issues/38484 See also https://github.com/ACCESS-NRI/ACCESS-OM2/issues/15
The failure above is worked around by temporarily adding the following line to packages/um7/package.py
:
After
version("7.3")
add
version("7.3-working", branch="4-create-a-working-debug-build")
This allows the following commands to succeed:
$ spack install um7@7.3-working%intel
$ spack install um7@7.3-working%intel opt=debug
I have not pushed this temporary change.
This pull request has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:
Hi @rxy900 Please review this merge request.
Thanks @rxy900 for the approval. I am also still waiting for your review of https://github.com/ACCESS-NRI/UM_v7/pull/5 to allow opt=debug
to work.
Merging now.
Closes issue #70. This is an initial Spack package for UM vn7.3, as a dependency of ACCESS-ESM1.5. See also issue #59.
Builds and installs as
um7%intel
. There is also an optionalum7%oneapi
but this has not yet been tested, and is not expected to work at the moment. See this comment to issue #59 for a possible extension to supportgcc
compilers.