Define CABLE science library Spack variant.

[bschroeter]

Further to the PR here:
CABLE-LSM/CABLE#479

We need a Spack variant that can build just the .a library object itself for use elsewhere.

My understanding is that I need to define a new variant in the following class to add the CABLE_LIBRARY flag to the cmake build:

https://github.com/ACCESS-NRI/spack-packages/blob/main/packages/cable/package.py

Which seems pretty straightforward so I will go ahead and do that once I have further info.

However, I'll need to call on the wisdom of someone familiar with the Spack CI infra (@harshula, @CodeGat?) as to how to actually activate the library build in Actions as the build appears traverse multiple repositories and I am unsure where to make changes.

One extra point to not is that the way it is set up, we may need to have build run both the mpi and library options as the CmakeLists.txt file in CABLE-LSM/CABLE#479 uses the cmake variable CABLE_MPI to set some additional compiler flags.

Any advice is greatly appreciated, apologies if anything is unclear!

[CodeGat]

Hmm, as in, how to test whether the variant will install (which would be covered under build-ci)? Or how to have a build of CABLE with the variant on Gadi for your own tests (which is under build-cd)?

[bschroeter]

Based on your comment, I would say both - at least that is my understanding.

We'd like to be able to test as part of our CI Action that the library builds as expected, but it is equally likely that we would like to have the library object deployed somewhere on Gadi so that users need not acquire the library via build artefacts just to put it on Gadi.

@ccarouge, can you confirm please?

[CodeGat]

For the former, I will need to fix ACCESS-NRI/build-ci#183
For the latter, ACCESS-NRI/CABLE-standalone could possibly be used?

[ccarouge]

Well it depends how we want the deployment of the coupled models to go. This library is to be used with ESM1.6 and AM/CM/ESM3 possibly. From what I see of the deployment of the coupled models, they use the deployment of the components (if they are already deployed). So I'm guessing @CodeGat is right and we should use ACCESS-NRI/CABLE-standalone. Although the name of the repository does not work anymore... But that's a minor inconvenience.

[bschroeter]

OK @CodeGat, I'll go ahead and implement the variant option in the package.py but I am guessing I won't be able to test until that issue is resolved.

Let me know if there is anything I can do on my end.

[CodeGat]

No worries, I'll work on it now and let you know when it's resolved

[bschroeter]

Thanks @CodeGat , changes in branch https://github.com/ACCESS-NRI/spack-packages/tree/178-define-cable-science-library-spack-variant.

I've made the changes following my discussion with @micaeljtoliveira last week. Please let me know if I have botched the syntax. Untested as yet.

[CodeGat]

Thanks @bschroeter - I think @harshula is the person you need for spack-packages syntax stuff, though!

[harshula]

Hi @bschroeter , It looks OK. Have you tested it?

[ccarouge]

@bschroeter I would assume you can test it on your own install without waiting for the CI to be updated. We still want the CI to be updated so breaking changes are spotted.

[harshula]

Hi @CodeGat , spack-packages has a new tag 2024.12.2 and that contains the updated cable SPR with the variant library. Can you please help @bschroeter set-up the model deployment repository's spack.yaml? Start by building without the library variant. Ben still has some work to do on the CMakeLists.txt before the library variant will work.

[CodeGat]

Sure thing. In this case, the Model Deployment Repository will be ACCESS-NRI/CABLE-standalone?

[harshula]

Sure thing. In this case, the Model Deployment Repository will be ACCESS-NRI/CABLE-standalone?

Hi @ccarouge , What's your preference regarding @CodeGat 's question?

[ccarouge]

Sure thing. In this case, the Model Deployment Repository will be ACCESS-NRI/CABLE-standalone?

@CodeGat Yes, that's the one.