Make spack packages for CICE6, MOM6, WWIII, access3-share

[anton-seaice]

Split the existing access-om3-nuopc package into several components, to produce the same result as the access-om3-nuopc package, split into components.

[anton-seaice]

We want to be able to build both the MOM6/CICE6 standalone and access builds.

According to the spack docs, it looks like you can only use git hashes/tags from one repository - see https://spack.readthedocs.io/en/latest/packaging_guide.html#fetching-from-code-repositories

I think this means that we would have one spack package for each component, which points to the access-nri fork, and a seperate spack package (contributed to the upstream spack repo) for the upstream build ?

Should we prefix out packages with access- so we can have different packages for the upstream version in the future.

i.e there is an access-cice package in this repository and a cice package in https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages ?

This seems like duplication, needing two spack packages for each model component ...

[anton-seaice]

As part of this work, I am making a access3-exe package.

The code to produce an executable for access-om3 and access-cm3 are the same ( https://github.com/ESCOMP/CMEPS/blob/main/cesm/driver/esmApp.F90 ), it just needs to be linked to different libraries.

for CM3, currently a lib is made like this:

# make UM library
object_files=""
for file in $ROSE_SUITE_DIR/share/fcm_make/build-atmos/o/*; do
    if [[ $file == *"driver.o" ]]; then
        echo $file
    elif [[ $file == *"um_main.o" ]]; then
        echo $file
    else
        object_files="${object_files} ${file}"
    fi
done

ar -r libum.a $object_files

and linked in through CMake . We should make sure the build is generic to access-om3/cm3/esm3 and avoid using 'om3' as a specific label if possible. ( e.g. in ACCESS-NRI/access3-share#2, change OM3 to Access3). Ill plan to leave the adding of UM to a later issue.

[q1165600785]

Have you finished making a separate mom6 package? I am using autoreconf to build, but after the build is successful, it always fails to run. I am looking forward to using spack to install mom6 without installing the dependencies required by mom6. Thanks for your hard work.

[aidanheerdegen]

According to the spack docs, it looks like you can only use git hashes/tags from one repository

@CodeGat pointed out this is just python, so maybe we could use some variant logic to choose which git repo to point to?

[anton-seaice]

@CodeGat pointed out this is just python, so maybe we could use some variant logic to choose which git repo to point to?

The current approach is ok - git hashes in the main repo can be found in the fork. Tags/branches however cannot unless they are added to the fork.

I suspect this is a can of worms? I can spend some time on it but it would be a change we want to make across lots of our recipes if it works ...

One advantage of using the upstream fork in the recipe is the possibility of submitting the package upstream to the main spack packages repo, not really possible if we add custom logic about which git repo to use ?