🔧 Standardize CMake install destinations and library naming (shared support, MSVC exports, python setup consistency)

[munechika-koyo]

Summary

To improve build/install consistency and simplify packaging, this change clarifies install destinations (RUNTIME/LIBRARY/ARCHIVE) across CMakeLists and unifies the layout using CMAKE_INSTALL_BINDIR and CMAKE_INSTALL_LIBDIR.
It also normalizes library output names (especially for static libraries) and aligns them with the Python wrappers (both setup.py.in and win.setup.py.in).
Shared library output is added or clarified for selected components, and MSVC export behavior is configured for Windows builds.

Key changes

• Unified and explicit install(TARGETS ...) destinations across CMakeLists:
  • RUNTIME -> CMAKE_INSTALL_BINDIR, LIBRARY/ARCHIVE -> CMAKE_INSTALL_LIBDIR
  • Explicit runtime/library/archive destinations for each target
• Library naming cleanup and output-name clarity:
  • Add a _static suffix for static libraries to avoid ambiguity against import libraries.
  • Restore conventional Windows import library naming/suffix handling
• Shared library support added/clarified (notably for serialisation)
• Windows/MSVC:
  • Add export configuration to ensure symbols are exported for shared builds
  • Keep conventional import library (.lib) naming
• extlib/portablexdr: install runtime artifacts into bindir
• Wrappers and apps:
  • Adjust install destinations for C++/Java wrappers and client/server to follow the policy above
  • Python: align naming in both setup.py.in and win.setup.py.in; simplify linking by collecting uda_libs into libraries

CMake install(TARGETS ...) and output type

Property	Description	Windows	UNIX	Recommended directory
RUNTIME	Files required at runtime	.exe, .dll	Executables	bin/
LIBRARY	Shared libraries		.so, .dylib	lib/
ARCHIVE	Static libraries, DLL import library	.lib	.a	lib/

Reference

• https://cmake.org/cmake/help/latest/command/install.html#signatures
• https://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Windows/MinGW_packages

Files touched (partial)

• CMakeLists.txt (root; MSVC export config, install layout)
• extlib/portablexdr-4.9.1/CMakeLists.txt (runtime -> bindir)
• source/bin/CMakeLists.txt, source/plugins/CMakeLists.txt
• source/{client,client2,server,server2}/CMakeLists.txt
• source/serialisation/CMakeLists.txt (shared support and naming adjustments)
• source/wrappers/{c++,java}/CMakeLists.txt
• source/wrappers/python/setup.py.in (naming and libraries list)
• source/wrappers/python/win.setup.py.in (naming consistency)

Compatibility/impact

• Downstream link settings that depend on library names (especially the _static suffix) may require updates.
• Executables/runtime artifacts (*.exe, *.dll at Windows) install to bindir (e.g., bin/), simplifying PATH setup and packaging.
• Python wrappers expect the normalized names; setup.py.in now aggregates uda_libs in the libraries list (for Unix machines).
• Windows/MSVC builds export symbols for shared libraries; import library naming remains conventional.
• No functional API/ABI changes; primarily cleanup of build/install definitions.

Review checklist

• Do all targets set runtime/library/archive destinations in install(TARGETS ...)?
• Are final static library names consistent with docs/scripts?
• Do wrappers (C++/Java/Python) link/reference the expected names? Does setup.py.in include uda_libs correctly?
• Is shared library generation and placement correct?
• On Windows/MSVC, are exports present and import libraries named as expected?
• Is extlib/portablexdr runtime placed under bindir?

Test instructions

• Standard build + install
  • Using a preset, or:

    cmake -S . -B build
    cmake --build build --config Release
    cmake --install build --prefix <prefix>

  • Verify the install layout under <prefix>/bin and <prefix>/lib(64)
• Wrappers
  • Python (Unix/Windows): build with setup.py.in; confirm the libraries list resolves via uda_libs and import succeeds
  • Windows: verify win.setup.py.in naming matches built artifacts and dynamic import works
• Windows/MSVC
  • Build shared libraries; ensure symbols are exported and import libraries are generated with conventional naming
• Sanity checks
  • On Unix/macOS, check linkage with ldd/otool on client/server and wrapper extensions

Notes

• This PR removes layout drift to increase predictability for build and distribution.

Related

• Simplifies existing packaging/distribution scripts (e.g., conda)
• Prevents issues caused by historical inconsistencies in install layouts

[munechika-koyo]

The build result, which was executed for the conda-forge repo, might help clarify which artifacts will be distributed.

[jholloc]

Hi. Thanks for your changes. Please could you rebase these onto 'develop' and reopen the PR from there?

[munechika-koyo]

@jholloc Thank you for your comment!
I attempted to change the destination branch and rebase it without recreating the PR.
Does this work for you?

[adam-parker1]

We triggered the CI for the ubuntu build to test this and we are seeing this error, please could you take a look

[munechika-koyo]

We triggered the CI for the ubuntu build to test this and we are seeing this error, please could you take a look

That was probably caused by the fact that I changed to use UDA shared libraries, rather than static libraries, in setup.py.
In the conda context, there is no problem because shared libraries are also available, and the cpyuda shared library is automatically linked to them. However, in the case of pypi, we should compile all of them into a cpyuda shared library.
So, I am considering implementing a switching parameter for the library we use (default is static libraries).

[adam-parker1]

We reran the CI but the ubuntu build is still failing with the following error during pyuda build
https://github.com/ukaea/UDA/actions/runs/17668707381/job/50685873947

[munechika-koyo]

@adam-parker1 Thank you for your suggestion!
I fixed the missing lib prefix and implemented the UDA_PYTHON_SHARED env to manage the UDA shared/static libraries.