Share prototype

[anton-seaice]

The goal of this repository is to provide all the code & build files to build access-om3. The repository has the code to build both common libraries which are used by model components, and to build an executable which contains models components build elsewhere.

There are two things to build:

• ACCESS3_LIB_INSTALL: this builds (static) libraries for CMEPS/CDEPS/share, which are then used by the model components (CICE, MOM6, WW3) & their driver code. This will be used by UM in the future also.
• OM3_BIN_INSTALL: this builds an executable using the esmApp in CMEPS and the model component required - this should support all combinations of including CICE/MOM6/WW3.

To-do:

• Decide if we remove the CMakePresets files - these are not used by Spack

[anton-seaice]

@micaeljtoliveira - If you can have a look at that would be great.

This works on my local machine for CICE6 only - see ACCESS-NRI/spack-packages#171

If the approach looks ok, we can make similar changes for MOM6 & WW3

[anton-seaice]

I am thinking about changing the export "Namespace" from Access3Share to just Share so the the CICE/MOM/WW Cmake packages are just importing a generic 'Share' package, rather than the Access3Share package.

I also wonder if the library install and bin install specific parts should be split into seperate files which are then included in CMakeLists (e.g. a Access3LibInstall.cmake file and a OM3BinInstall.cmake file)

[anton-seaice]

I also think I will change OM3_BIN_INSTALL to ACCESS3_BIN_INSTALL because the same Cmake package can be used for Access-cm3/esm3

[micaeljtoliveira]

@anton-seaice Before going into the details, here are a few general things to discuss.

Looking at how the top CMakeLists.txt file is taking shape, I think it would be better to have a clean separation between the "shared" libraries and the driver, as they have very little in common and the current setup is quite confusing if you are not familiar with it.

One option is to have two separate files, as you mentioned above. The other one is to have two different projects. The later might actually be simpler and cleaner, specially because all the sources are included via git submodules.

Regarding namespaces, there are two different scopes: CMake variables (e.g., OM3_BIN_INSTALL) and the exported targets (e.g., Access3Share::cdeps_common). Although we should try to make them all unique, the context in which they are used is different. The variables need to be unique to allow for a CMake project to directly fetch and build another CMake project, which is something that we are not planning on doing, so it's not so critical. As for the exported targets, nothing prevents you from using the same namespace across different projects. So you could actually use Access and have Access::timing, Access::cmeps, Access::MOM6, etc. I think this would better translate the purpose of the different libraries: they are the components used to build the ACCESS models.

[anton-seaice]

Thanks!

The other one is to have two different projects. The later might actually be simpler and cleaner, specially because all the sources are included via git submodules.

Thanks - does this mean seperate repositories ? Or just seperate CMakeLists.txt files in different folders? The two projects would have some duplication I think - e.g. most of the "Project Configuration section" - compiler flags, Fortranlib, MODULEDIR, FindESMF

[micaeljtoliveira]

Thanks - does this mean seperate repositories ? Or just seperate CMakeLists.txt files in different folders? The two projects would have some duplication I think - e.g. most of the "Project Configuration section" - compiler flags, Fortranlib, MODULEDIR, FindESMF

Yes, I meant two repositories and yes, there would be some duplication. I would say that's acceptable, because none of the duplicated code is likely to change often, if at all. That being said, you can also have two different project in the same repository. That would be a third option to consider.

[anton-seaice]

I think we will want to change CMEPS versions & code more often that we need to look at the CMake files, so my preference is to only have CMEPS code in one repository. Along those lines, I created two .cmake files, which can be included. One has the library specifics and one has the executable specifics.

I poked around the NCAR Cmake a bit, they don't use namespaces for the exports. So ill just change the namespace from Access3Share to Access3 and we can put all the model components in that namespace also.

[micaeljtoliveira]

@anton-seaice Great to have the two .cmake files, makes the code easier to follow. Just one thing that is confusing (and potentially wrong?): I don't think one could build both the libraries and the binaries at the same time, due to the dependencies that sit in the middle (MOM6, CICE6, etc). So it would probably be less error-prone and clearer if the two options (ACCESS3_LIB_INSTALL and ACCESS3_BIN_INSTALL) where mutually exclusive. What do you think?