Implement component-based package generation
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 usingADD_NEKTAR_TEST(<name> LENGTHY)
to avoid duplicating the macro. - Object libraries can now be created for solvers by using the
LIBRARY_SOURCES
argument to theADD_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