Update cmake configuration

[Yaswant Pradhan (yaswant)]

PR Summary

This change finishes the CMake install parity work so downstream consumers (e.g., Mule) get the same critical install artifacts expected from the legacy build flow.

Code Reviewer: Sam Clarke-Green (@t00sa)

What's changed

1. Added installation of standalone shared libraries for key subcomponents:
   • libshum_constants.so
   • libshum_string_conv.so
   • libshum_wgdos_packing.so
   • libshum_byteswap.so
   • libshum_spiral_search.so
2. Added installation of missing public headers:
   • shumlib_version.h
   • c_shum_wgdos_packing_version.h
3. Optionally, added generation of the WGDOS version compatibility header from a template, and ensured it defines SHUMLIB_VERSION for external consumers before including shumlib_version.h.
4. Added install-time symlink creation so the install prefix contains:
   • lib64 directory for libraries
   • lib symlink pointing to lib64
5. Fixed source/include path handling for new sub-library CMake targets to use project-root-qualified paths, preventing missing-source errors during configure/build.

This keeps the existing aggregate library behaviour while adding/installing the required standalone targets and compatibility headers needed by downstream users.

I'll add an example wrapper script in MetOffice/mule in a separate Mule PR.

Checks

• Configure/build/install succeeds with CMake.
• Install tree contains the expected five shared libraries in lib64.
• Install tree contains the expected headers in include.
• Prefix contains lib symlink to lib64.

Code Quality Checklist

(Some checks are automatically carried out via the CI pipeline)

• I have performed a self-review of my own code
• My code follows the project's style guidelines
• Comments have been included that aid undertanding and enhance the
  readability of the code
• My changes generate no new warnings

Testing

• I have tested this change locally, using the rose-stem suite
• If any tests fail (rose-stem or CI) the reason is understood and
  acceptable (eg. kgo changes)
• I have added tests to cover new functionality as appropriate (eg. system
  tests, unit tests, etc.)

trac.log

Security Considerations

• This change does not introduce security vulnerabilities
• I have reviewed the code for potential security issues
• Sensitive data is properly handled (if applicable)
• Authentication and authorisation are properly implemented (if applicable)

Performance Impact

• Performance of the code has been considered and, if applicable, suitable
  performance measurements have been conducted

AI Assistance and Attribution

• Some of the content of this change has been produced with the assistance
  of Generative AI tool name (e.g., Met Office Github Copilot Enterprise,
  Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the
  Simulation Systems AI policy(including attribution labels)

Documentation

• Where appropriate I have updated documentation related to this change and
  confirmed that it builds correctly

Code Review

• All dependencies have been resolved
• Related Issues have been properly linked and addressed
• CLA compliance has been confirmed
• Code quality standards have been met
• Tests are adequate and have passed
• Documentation is complete and accurate
• Security considerations have been addressed
• Performance impact is acceptable

[Yaswant Pradhan (yaswant)]

Trying to compile with Ninja caught some useful issues, e.g.,:

[53/177] Generating Fortran dyndep file shum_constants/src/CMakeFiles/shum_constants.dir/Fortran.dd
ninja: build stopped: multiple rules generate modules/f_shum_chemistry_constants_mod.mod.

This is a classic Ninja dyndep conflict: both shum and shum_constants (and other standalone targets) compile the same .f90 files and write .mod files to the shared modules/ (${CMAKE_Fortran_MODULE_DIRECTORY}) directory, so two rules claim ownership of the same .mod file. Make silently overwrites (so did not catch this in my original changes); Ninja rejects it.

The fix is to give each standalone target its own private Fortran_MODULE_DIRECTORY. Transitive target_link_libraries already propagates each library's module path to dependents (e.g. shum_byteswap -> shum_string_conv), so cross-lib compilation still works correctly.

I think the whole project can be CMake-refactored, once we deprecate the legacy approach.

Additional changes in 25d97c3

[Sam Clarke-Green (t00sa)]

This PR contains a number of unrelated changes. They need to be split up into separate changes.

The core of the change reinstates features that were removed during the migration to CMake, e.g. multiple libraries and the convoluted versioning of different routines. If there are dependencies, e.g. mule, that expect these features, the solution is to modernise the dependency, not to reintroduce obsolete features back into shumlib.