Add CMake build system and Pkgconf pc file

[harshula]

[Update: 22/07/2025]

• New: option(BUILD_SHARED_LIBS "Build shared/dynamic libraries" OFF)

[micaeljtoliveira]

@harshula Here are some comments plus a couple of questions.

[harshula]

Update

The Spack interaction with upstream netcdf-fortran (autotools), ACCESS-NRI's FMS (CMake) and ACCESS-NRI's GFDL-generic-tracers (CMake) is complicated if we don't use pkgconf and use CMake's native find_package().

Spack's netcdf-fortran SPR builds via autotools. i.e. No CMake exports. Spack's FMS SPR builds via CMake and uses the FindNetCDF.cmake file that resides within FMS. I've modified ACCESS-NRI's FMS to do the same instead of using pkgconf. When I made the changes, that were recommended above, and switched ACCESS-NRI's GFDL-generic-tracers from using pkgconf to CMake's find_package to find FMS, CMake looks for a FindNetCDF.cmake in GFDL-generic-tracers too. Adding a file to accommodate a dependency's dependency is bad practice.

I had a chat with @micaeljtoliveira about this on Friday. He suggested trying to export the FindNetCDF.cmake in FMS. So this PR will be paused till ACCESS-NRI's FMS is updated.

[dougiesquire]

This has been tested fairly extensively in ACCESS models. Results here: ACCESS-NRI/access-spack-packages#238 (comment)

[dougiesquire]

One change below and then this is good to go from my perspective (noting that I haven't tested the PkgConfig).

[dougiesquire]

@harshula, once we get @JorgeG94's update for the mocsy dependency into this branch are you okay for me to (squash and) merge?

This has now been pretty well tested. If there's additional testing you want to do, could it continue after merging?

[harshula]

Hi @dougiesquire , I'll try to finish my testing this week and I'll merge it.

21/07/2025 - Added support to build the library as shared/dynamic.

[dougiesquire]

@harshula is your plan to "Squash and merge" this?

[harshula]

Hi @dougiesquire , No, there'll be a merge commit. These commits will all be independent.

[dougiesquire]

My preference is to "squash and merge" to minimize the number of commits we carry ahead of upstream. Are you okay with that?

[harshula]

Hi @dougiesquire , A merge commit is different from a 'rebase and merge', where all the commits appear linearly in the git commit history and hence difficult to isolate to a single PR/merge. The merge commit provides isolation of a series of commits. e.g. git revert of the merge commit reverts the entire series of commits. I'll be doing a merge commit to keep the functional changes in separate commits but the series will isolated and grouped together via the merge commit. i.e. If you view the log via a graphical/tree diff, you'll clearly see this series of commits grouped together.

[dougiesquire]

Yup, I understand that difference thanks. But I said "squash and merge", not "rebase and merge". As I mentioned, we're trying to keep clean and minimize the commits on main that are ahead of upstream. You can include the PR number in the squashed commit message (the Github UI defaults to this) so that the individual commits in this PR can still be easily found.

[harshula]

Hi @dougiesquire , Your reasoning sounded like you are confusing a merge commit with 'rebase and merge'. Try using git log --graph. The merge commit achieves the isolation you want and additionally keeps the functional changes in separate commits.
If you want to properly track an upstream repo, try using a strategy like we do for our Spack fork. I'm happy to help with that. I'm afraid the current GFDL-generic-tracers main does not look like it is tracking https://github.com/NOAA-GFDL/ocean_BGC/commits/main/ .

[dougiesquire]

Your reasoning sounded like you are confusing a merge commit with 'rebase and merge'. Try using git log --graph. The merge commit achieves the isolation you want and additionally keeps the functional changes in separate commits.

Nah I'm not confusing them. I'm just trying to keep the commits on main clean/minimal and as linear as possible.

[harshula]

Notes
Waiting on the test runs. If they are successful, then I'll rebase all the commits to ensure they all have the same last modified date and then do a merge commit.

[dougiesquire]

Apologies, testing was held up by a dependency bug in model-config-tests and Payu

[dougiesquire]

Summary of results of testing with dev-1deg_jra55_ryf+wombatlite config:

• Adding support for shared fms, mocsy, gtracers libs does not change answers (expected)
• Building ACCESS-OM2 with shared fms, mocsy, gtracers libs does change answers (by a tiny amount)

Thanks for this long slog @harshula. I'm happy to merge. Don't forget to rebase :)