441 investigate compiling science code as library

[bschroeter]

Description

Added some base implementation ideas for the "build as library" objective.

Following discussions with @ccarouge, source files in offline have been copied to a new coupled/esm16 directory and configured in CMakeLists.txt with a new --library flag that can be passed to build.bash.

Passing in this flag will build the science source into a library using parts of the esm16 and science directories, then build the executable and link the two. Based on conversations, we will probably want the library aspect to be isolated from the building of executables - correct me if I am wrong.

I do not think this is quite where we want it to be just yet, but pushing to spur conversation and further clarity on needs.

I've left the old CMakeList.txt there for reference with a .bk suffix, but will remove once this PR progresses.

Type of change

• Enhancement

Checklist

• The new content is accessible and located in the appropriate section.
• I have checked that links are valid and point to the intended content.
• I have checked my code/text and corrected any misspellings

Please add a reviewer when ready for review.

---

📚 Documentation preview 📚: https://cable--479.org.readthedocs.build/en/479/

[bschroeter]

Oops. this shouldn't be here. will delete next commit

[bschroeter]

@ccarouge, I have updated the branch to reflect upstream changes since checkout.

There is a new --library flag available to build.bash that compiles the science library only and disables binary installation.

As per the above comments, there are a handful of files copied from offline into coupled/esm16. These are the files that will likely be clobbered by developments, but the fact that they are in there means that libscable_science.a actually compiles.

[access-hive-bot]

This pull request has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/esm1-6-land-meeting-notes/3831/7

[ccarouge]

Seems good, but you've got complex conflicts to solve it seems (that's what GitHub says at least). Time for a rebase before getting this in I believe.

[JhanSrbinovsky]

I get what you mean dependencies now -

This was in ESM1.5. Whether it is going to be needed for ESM1.6 isnt clear. At any rate it was far easier to include it in the build than untangle it in the short term

[JhanSrbinovsky]

This was in ESM1.5. Appropriate to CABLE 2.4. Ideally all of the other applications will pickup the AM3 "approach". But this is not likely to happen, nor necessary, for a while. When we move on with JAC this will hopefully all get sorted and we'll just have a single version across all apps

[JhanSrbinovsky]

Across apps this module is different but at least the science code is tricked to all use it. One day there will be 2 versions only. The UM7.X and offline versions will never be able to pick up the coupled versions that use the UM/JULES IO to read surface_types from a namelist.

[bschroeter]

@ccarouge, conflicts resolved. Quick, lets merge it!

[ccarouge]

All good.