Skip to content

Tidy up CMake infrastructure

Dave Moxey requested to merge dmoxey/nektar:feature/cmake-cleanup into master

This MR updates quite a bit of internal CMake infrastructure to tidy things up.

  • Macros have been updated to be more CMake-like, remove the need for source code variables and provide rudimentary dependency tracking to support the package creation. Some examples:
# library generation
ADD_NEKTAR_LIBRARY(LibUtilities
    DESCRIPTION "Nektar++ LibUtilities library"
    SOURCES ${LibUtilitySources}
    HEADERS ${LibUtilityHeaders})

# One-line executable generation, specifying a component by hand (in this case
# a demo)
ADD_NEKTAR_EXECUTABLE(NodalDemo
    COMPONENT demos DEPENDS LibUtilities SOURCES NodalDemo.cpp)

# Solver generation: automatically creates a new component, IncNavierStokesSolver
ADD_SOLVER_EXECUTABLE(IncNavierStokesSolver
    SOURCES IncNavierStokesSolver.cpp
    LIBRARY_SOURCES
    EquationSystems/CoupledLinearNS.cpp
    EquationSystems/CoupledLocalToGlobalC0ContMap.cpp
    EquationSystems/IncNavierStokes.cpp
    ...)
  • Object libraries can now be created for solvers by using the LIBRARY_SOURCES argument to the ADD_SOLVER_EXECUTABLE macro. These are temporary static libraries containing the link results of the specified files. This means that if there are derivative utilities, they can link against the object library and avoid re-compiling solver files.
  • Added a dev component which contains library headers so that eventually external developers can compile code against our libraries.
  • Toggling NEKTAR_BUILD_SOLVERS now removes solvers from the configuration list in ccmake.
  • Toggling NEKTAR_BUILD_UTILITIES now allows one to select building FieldConvert, NekMesh and extra utilities independently.
  • Removed ADD_NEKTAR_TEST_LENGTHY in deference to using ADD_NEKTAR_TEST(<name> LENGTHY) to avoid duplicating the macro.
  • Removed pkg/homebrew and pkg/macports as they should live in separate external repositories
  • Added a new macro, THIRDPARTY_LIBRARY, which is used to point to the exact location of a third-party build library instead of adding -llibname to the linker flags. This avoids the issue of e.g. linking against an outdated system zlib installation.
  • A large number of obsolete files (i.e. code that is not compiled, some very old autotools files, and old utilities that are now part of FieldConvert) have been removed.
Edited by Dave Moxey

Merge request reports