Skip to content

Implement component-based package generation

Dave Moxey requested to merge dmoxey/nektar:feature/pkg-component into master

This MR updates quite a bit of our internal CMake infrastructure to support component-based package generation. In this setting, components are specified when adding executables or libraries, and for Debian/RPM-based architectures, one package is generated per component. Most of this is wrapped up into the existing ADD_NEKTAR_* commands, which have been updated a bit to allow for rudimentary dependency tracking. This is a bit more robust than the existing system since everything tracks the CMake configuration, and gives a bit more control over the packages that are being generated, since they will be built according to whatever is enabled in the CMake options.

A more piecemeal list of changes this MR introduces:

  • 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
    ...)
  • Added a dev package which contains library headers so that external developers can compile code against our libraries.
  • Removed the make pkg-* commands in deference to just issuing the command
cpack -G GeneratorName

from the build directory.

  • Removed ADD_NEKTAR_TEST_LENGTHY in deference to using ADD_NEKTAR_TEST(<name> LENGTHY) to avoid duplicating the macro.
  • 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 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, or old utilities that are now part of FieldConvert) have been removed.
  • MPI will now be compiled if it is not present on the system and NEKTAR_USE_MPI is switched on. This is to support the generation of an OS X package that still retains parallel support.
  • A bit of tidying of the CMake code where appropriate

Merge request reports