OilfieldToolsNet/opm-core
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
2b7e3f87599a0b77c8f37b9ed0939a14641d682f
opm-core/CMakeLists.txt

457 lines
15 KiB
CMake
Raw Normal View History

Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
# -*- mode: cmake; tab-width: 2; indent-tabs-mode: t; truncate-lines: t; compile-command: "cmake -Wdev" -*-
# vim: set filetype=cmake autoindent tabstop=2 shiftwidth=2 noexpandtab softtabstop=2 nowrap:
cmake_minimum_required (VERSION 2.8)
project (opm-core)
Set version number to 1.0 in anticipation of release Version numbers for the library follow ABI-style and is independent of the ones for releases. If the interface breaks, we change the soversion, regardless of the timing of the releases.
2013-01-16 13:47:02 +01:00
set (opm-core_VERSION_MAJOR 1)
set (opm-core_VERSION_MINOR 0)
Probe for C99 standard available Similar to the -std=c++0x flag for C++ code, we probe for, and add if available, -std=c99 for C code, since the compiler may generate different initialization code for this variant. The reporting from the bundled CMake modules is not as polished as for probing for C++ flags, but not bad enough to warrant rewriting the code from scratch just to fix the output.
2012-12-10 12:25:40 +01:00
enable_language (C)
Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
enable_language (CXX)
Debug build by default In this stage of development it is assumed that having a build that is easy to debug from within an IDE has the most value for most users. If any speed comparisons are to be done, be sure to configure with -DCMAKE_BUILD_TYPE=Release
2012-11-29 21:22:40 +01:00
# build debug by default
if (NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
set (CMAKE_BUILD_TYPE "Debug")
endif (NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
message (STATUS "Build type: ${CMAKE_BUILD_TYPE}")
Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
# all public header files are together with the source
Separate defines for this library from those of deps This makes it easier to write this list to the config-mode module and let it merge with those from dependencies in the user's program (although that implies that we no longer pretend that inconsistencies are not possible). The convention that singular form contains values for this project alone whereas plural form contains values for both this project and dependencies, is used.
2012-12-05 11:01:18 +01:00
set (opm-core_INCLUDE_DIR "${PROJECT_SOURCE_DIR}")
list (APPEND opm-core_INCLUDE_DIRS "${opm-core_INCLUDE_DIR}")
Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
Put results of platform checks in configuration header Various features in the code base will be enabled depending on the values written by the build system in here.
2012-11-14 12:46:35 +01:00
# additional search modules
Install the library and headers Enables running `make && make install` on a target system. Documentation is not yet built or installed.
2012-12-07 08:58:18 +01:00
set (opm-core_MODULE_DIR "${PROJECT_SOURCE_DIR}/cmake/Modules")
list (APPEND CMAKE_MODULE_PATH ${opm-core_MODULE_DIR})
Put results of platform checks in configuration header Various features in the code base will be enabled depending on the values written by the build system in here.
2012-11-14 12:46:35 +01:00
Provide backward-compatibility modules for older CMakes BLAS module originally required Fortran to be enabled, newer module doesn't; LAPACK module had some spelling errors that prevented it from working; and cmake_push_check_state() is not available before 2.8.6.
2013-01-22 14:12:16 +01:00
# include special
if (CMAKE_VERSION VERSION_LESS "2.8.7")
message (STATUS "Enabling backward compatibility modules for CMake ${CMAKE_VERSION}")
list (APPEND CMAKE_MODULE_PATH "${opm-core_MODULE_DIR}/compat-2.8.7")
endif (CMAKE_VERSION VERSION_LESS "2.8.7")
Use only necessary libraries
2013-01-24 23:07:55 +01:00
# don't import more libraries than we need to
include (UseOnlyNeeded)
Add compiler options that may make the builds faster Sometimes compiler options can help doing faster builds; for GCC the pipe option will help interleave the various stages of the build.
2012-12-07 10:14:10 +01:00
# use tricks to do faster builds
include (UseFastBuilds)
Use precompiled headers to compile C++ modules On an average system this will cut around 15% of the total build time. Unfortunately, including Boost headers in the precompiled header takes longer time to generate and then read in each module, than just including the necessary headers in each module. Use Noel Llopis' list_precomp.py at http://www.gamesfromwithin.com/wp-content/uploads/bin/list_precomp_py.txt to analyse which headers are included the most and are candidates for inclusion.
2013-01-23 14:35:50 +01:00
# precompiled headers
include (UsePrecompHeaders)
Use generic boilerplate macro to include packages
2012-11-28 10:44:54 +01:00
# macro to set standard variables (INCLUDE_DIRS, LIBRARIES etc.)
Rename macro modules Modules that starts with the prefix "Use" alters the build to enable something by default, whereas modules that only provide functionality is not common to start with that prefix.
2012-12-05 09:34:38 +01:00
include (OpmFind)
Use generic boilerplate macro to include packages
2012-11-28 10:44:54 +01:00
Use declarative list of dependencies instead of functions
2012-12-05 09:59:38 +01:00
# dependencies
list (APPEND opm-core_DEPS
Probe for C99 standard available Similar to the -std=c++0x flag for C++ code, we probe for, and add if available, -std=c99 for C code, since the compiler may generate different initialization code for this variant. The reporting from the bundled CMake modules is not as polished as for probing for C++ flags, but not bad enough to warrant rewriting the code from scratch just to fix the output.
2012-12-10 12:25:40 +01:00
# compile with C99 support if available
"C99"
Use declarative list of dependencies instead of functions
2012-12-05 09:59:38 +01:00
# compile with C++0x/11 support if available
C++11 is only recommended, not required If we don't have a C++11 compiler, we won't be able to build DUNE, but opm-core is still usable with for instance UMFPACK. However, if it *is* available, it should be used to improve the ABI compatibility with other parts of the suite.
2012-12-07 10:16:59 +01:00
"CXX11Features"
Use declarative list of dependencies instead of functions
2012-12-05 09:59:38 +01:00
# matrix library
"BLAS REQUIRED"
"LAPACK REQUIRED"
# Tim Davis' SuiteSparse archive
"SuiteSparse COMPONENTS umfpack"
# solver
"SUPERLU"
# xml processing (for config parsing)
Use system TinyXML if available; otherwise our own
2013-01-22 15:03:07 +01:00
"TinyXML"
Use declarative list of dependencies instead of functions
2012-12-05 09:59:38 +01:00
# various runtime library enhancements
"Boost 1.39.0
COMPONENTS date_time filesystem system unit_test_framework REQUIRED"
# DUNE dependency
"dune-istl"
Search for ERT and include in build if found If the OpenMP flag is added to the build, this should probably be propagated to the user programs as well.
2012-12-19 10:58:39 +01:00
# Ensembles-based Reservoir Tools (ERT)
"ERT"
Use declarative list of dependencies instead of functions
2012-12-05 09:59:38 +01:00
)
find_and_append_package_list (${opm-core_DEPS})
Compile with C++0x/11 if available We want to compile with the -std=c++0x since DUNE uses this settings and we need to use the same ABI as that one if we are going to link with it. Find module is a copy of the one in cmake/modules in (the cmake branch of) dune-common.
2012-11-16 14:40:54 +01:00
Enable debugging support
2012-11-29 12:36:29 +01:00
# put debug information into every executable
include (UseDebugSymbols)
Enable optimization
2012-11-29 13:09:56 +01:00
# optimize full if we're not doing a debug build
include (UseOptimization)
Enable all warnings
2012-11-29 13:12:13 +01:00
# turn on all warnings
include (UseWarnings)
Use declarative list of dependencies instead of functions
2012-12-05 09:59:38 +01:00
# detect if Boost is in a shared library
Check for dynamic linking of Boost::Test library BOOST_TEST_DYN_LINK must be defined if you are *building* Boost::Test as a shared object, and the client programs must also include this option when they use the header files, to link to it correctly.
2012-11-23 13:44:32 +01:00
include (UseDynamicBoost)
Link with C++ Boost library
2012-11-17 00:36:54 +01:00
Enable support for multi-arch on Debian/Ubuntu
2013-01-16 23:36:16 +01:00
# needed for Debian installation scheme
include (UseMultiArch)
# put libraries in lib/ (no multi-arch support in build tree)
Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
set (CMAKE_LIBRARY_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib")
Put static libraries in the same directory as shared
2013-02-01 22:27:23 +01:00
set (CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib")
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
set (CMAKE_RUNTIME_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/bin")
Keep build dir tidy by relocating Fortran modules If we are building in-source, we don't want to have a bunch of output files in the root directory; instead we put them in CMakeFiles/ where all the rest of the object files go.
2012-12-21 10:09:42 +01:00
set (CMAKE_Fortran_MODULE_DIRECTORY "${PROJECT_BINARY_DIR}/CMakeFiles")
Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
Sources are named after library, not project All targets in the project uses variables defined on a "project" basis whereas only a specific target uses variables named after it.
2012-12-07 13:07:04 +01:00
# find all the source code (note that these variables have name after
Explain why globs can be used to enumerate source code The documentation argues against it, but I believe it uses flawed reasoning.
2012-12-21 09:30:36 +01:00
# the target library and not the project). the documentation recommends
# against using globs to enumerate source code, but if you list the
# files explicitly you'll change the build files every time you add to
# the project as well as having to rebuild completely anyway.
Use precompiled headers to compile C++ modules On an average system this will cut around 15% of the total build time. Unfortunately, including Boost headers in the precompiled header takes longer time to generate and then read in each module, than just including the necessary headers in each module. Use Noel Llopis' list_precomp.py at http://www.gamesfromwithin.com/wp-content/uploads/bin/list_precomp_py.txt to analyse which headers are included the most and are candidates for inclusion.
2013-01-23 14:35:50 +01:00
file (GLOB_RECURSE opmcore_C_SOURCES "opm/core/[^.]*.c")
file (GLOB_RECURSE opmcore_CXX_SOURCES "opm/core/[^.]*.cpp")
file (GLOB_RECURSE opmcore_C_HEADERS "opm/core/[^.]*.h")
file (GLOB_RECURSE opmcore_CXX_HEADERS "opm/core/[^.]*.hpp")
# remove pre-compile headers from output list
set (opmcore_PRECOMP_CXX_HEADER "opm/core/opm-core-pch.hpp")
list (REMOVE_ITEM opmcore_CXX_HEADERS
${PROJECT_SOURCE_DIR}/${opmcore_PRECOMP_CXX_HEADER}
)
# merge both languages into one compilation/installation
set (opmcore_SOURCES ${opmcore_C_SOURCES} ${opmcore_CXX_SOURCES})
set (opmcore_HEADERS ${opmcore_C_HEADERS} ${opmcore_CXX_HEADERS})
Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
Compile and link Algebraic Multigrid, if available If the path to Notay's AGMG library is provided through the cache variable AGMG_ROOT, then include this in the build and enable the test. It would have been desirable to use the variable name AGMG_DIR for consistency with the other modules, but unfortunately this name will alter the functionality of CMake's find_package.
2012-12-13 00:28:32 +01:00
# Algebraic Multigrid must be compiled together with our program;
# if it is not available, then remove our corresponding component
find_package (AGMG)
if (AGMG_FOUND)
list (APPEND opmcore_SOURCES ${AGMG_SOURCES})
Only compile in support for solvers that are found
2013-01-22 15:23:24 +01:00
endif (AGMG_FOUND)
# these solvers are only compiled in if their dependency is found
if (NOT AGMG_FOUND)
Compile and link Algebraic Multigrid, if available If the path to Notay's AGMG library is provided through the cache variable AGMG_ROOT, then include this in the build and enable the test. It would have been desirable to use the variable name AGMG_DIR for consistency with the other modules, but unfortunately this name will alter the functionality of CMake's find_package.
2012-12-13 00:28:32 +01:00
list (REMOVE_ITEM opmcore_SOURCES
${PROJECT_SOURCE_DIR}/opm/core/linalg/LinearSolverAGMG.cpp
)
Only compile in support for solvers that are found
2013-01-22 15:23:24 +01:00
endif (NOT AGMG_FOUND)
if (NOT dune-istl_FOUND)
list (REMOVE_ITEM opmcore_SOURCES
${PROJECT_SOURCE_DIR}/opm/core/linalg/LinearSolverIstl.cpp
)
endif (NOT dune-istl_FOUND)
if (NOT SuiteSparse_FOUND)
list (REMOVE_ITEM opmcore_SOURCES
${PROJECT_SOURCE_DIR}/opm/core/linalg/call_umfpack.c
${PROJECT_SOURCE_DIR}/opm/core/linalg/LinearSolverUmfpack.cpp
)
endif (NOT SuiteSparse_FOUND)
Compile and link Algebraic Multigrid, if available If the path to Notay's AGMG library is provided through the cache variable AGMG_ROOT, then include this in the build and enable the test. It would have been desirable to use the variable name AGMG_DIR for consistency with the other modules, but unfortunately this name will alter the functionality of CMake's find_package.
2012-12-13 00:28:32 +01:00
Remove files which are not part of the official library Some files are distributed with the source, but does not end up in the final shared object. These files are captured by the glob, so we have to remove them afterwards. (There are fewer of these files than explicitly list all files that should be included in the build).
2012-11-14 12:51:19 +01:00
# these files are provided in source control, but can only compile with Matlab
Use system TinyXML if available; otherwise our own
2013-01-22 15:03:07 +01:00
# available; we are not supposed to include the TinyXML test prog. regardless
Sources are named after library, not project All targets in the project uses variables defined on a "project" basis whereas only a specific target uses variables named after it.
2012-12-07 13:07:04 +01:00
list (REMOVE_ITEM opmcore_SOURCES
Remove files which are not part of the official library Some files are distributed with the source, but does not end up in the final shared object. These files are captured by the glob, so we have to remove them afterwards. (There are fewer of these files than explicitly list all files that should be included in the build).
2012-11-14 12:51:19 +01:00
${PROJECT_SOURCE_DIR}/opm/core/grid/cpgpreprocess/mxgrdecl.c
${PROJECT_SOURCE_DIR}/opm/core/grid/cpgpreprocess/processgrid.c
${PROJECT_SOURCE_DIR}/opm/core/utility/parameters/tinyxml/xmltest.cpp
)
Use system TinyXML if available; otherwise our own
2013-01-22 15:03:07 +01:00
# remove inline TinyXML if a system version was found
if (TinyXML_FOUND)
file (GLOB_RECURSE _inline_tinyxml "opm/core/utility/parameters/tinyxml/*")
foreach (_file IN LISTS _inline_tinyxml)
list (REMOVE_ITEM opmcore_SOURCES ${_file})
endforeach (_file)
endif (TinyXML_FOUND)
Remove TinyXML from list of headers to be installed
2013-01-23 09:08:42 +01:00
# anyhow remove it from the header list (so it doesn't get installed)
list (REMOVE_ITEM opmcore_HEADERS "opm/core/utility/parameters/tinyxml/tinystr.h")
list (REMOVE_ITEM opmcore_HEADERS "opm/core/utility/parameters/tinyxml/tinyxml.h")
Search for ERT and include in build if found If the OpenMP flag is added to the build, this should probably be propagated to the user programs as well.
2012-12-19 10:58:39 +01:00
# HAVE_ERT is used as an #ifdef, not as an #if in the source code, if it
# is not true, then it should be unset altogether
if (NOT HAVE_ERT)
set (HAVE_ERT)
endif (NOT HAVE_ERT)
Put results of platform checks in configuration header Various features in the code base will be enabled depending on the values written by the build system in here.
2012-11-14 12:46:35 +01:00
# create configuration header which describes available features
Separate defines for this library from those of deps This makes it easier to write this list to the config-mode module and let it merge with those from dependencies in the user's program (although that implies that we no longer pretend that inconsistencies are not possible). The convention that singular form contains values for this project alone whereas plural form contains values for both this project and dependencies, is used.
2012-12-05 11:01:18 +01:00
# necessary to compile this library. singular version is the names that
# is required by this project alone, plural version transitively
# includes the necessary defines by the dependencies
Rename macro modules Modules that starts with the prefix "Use" alters the build to enable something by default, whereas modules that only provide functionality is not common to start with that prefix.
2012-12-05 09:34:38 +01:00
include (ConfigVars)
Separate defines for this library from those of deps This makes it easier to write this list to the config-mode module and let it merge with those from dependencies in the user's program (although that implies that we no longer pretend that inconsistencies are not possible). The convention that singular form contains values for this project alone whereas plural form contains values for both this project and dependencies, is used.
2012-12-05 11:01:18 +01:00
set (opm-core_CONFIG_VAR
HAVE_AGMG
HAVE_DUNE_ISTL
HAVE_DYNAMIC_BOOST_TEST
HAVE_ERT
HAVE_SUITESPARSE_UMFPACK_H
HAVE_NULLPTR
HAVE_STATIC_ASSERT
Put results of platform checks in configuration header Various features in the code base will be enabled depending on the values written by the build system in here.
2012-11-14 12:46:35 +01:00
)
Separate defines for this library from those of deps This makes it easier to write this list to the config-mode module and let it merge with those from dependencies in the user's program (although that implies that we no longer pretend that inconsistencies are not possible). The convention that singular form contains values for this project alone whereas plural form contains values for both this project and dependencies, is used.
2012-12-05 11:01:18 +01:00
list (APPEND opm-core_CONFIG_VARS ${opm-core_CONFIG_VAR})
Put results of platform checks in configuration header Various features in the code base will be enabled depending on the values written by the build system in here.
2012-11-14 12:46:35 +01:00
configure_vars (
Write config variables in either C++ or CMake syntax We need the list of variables to put in config.h for the CMake config- mode module; reuse the code that writes the list to config.h in the first place to also write CMake-compatible lines.
2012-12-05 12:53:37 +01:00
FILE CXX "${PROJECT_BINARY_DIR}/config.h"
Put results of platform checks in configuration header Various features in the code base will be enabled depending on the values written by the build system in here.
2012-11-14 12:46:35 +01:00
WRITE ${opm-core_CONFIG_VARS}
)
Compile and link Algebraic Multigrid, if available If the path to Notay's AGMG library is provided through the cache variable AGMG_ROOT, then include this in the build and enable the test. It would have been desirable to use the variable name AGMG_DIR for consistency with the other modules, but unfortunately this name will alter the functionality of CMake's find_package.
2012-12-13 00:28:32 +01:00
include (UseFortranWrappers)
define_fc_func (
APPEND "${PROJECT_BINARY_DIR}/config.h"
)
Put results of platform checks in configuration header Various features in the code base will be enabled depending on the values written by the build system in here.
2012-11-14 12:46:35 +01:00
Use generic boilerplate macro to include packages
2012-11-28 10:44:54 +01:00
# some CMake properties do not do list expansion
string (REPLACE ";" " " opm-core_LINKER_FLAGS_STR "${opm-core_LINKER_FLAGS}")
Make building libraries static or shared selectable Default is still to make a shared object because this is the most versatile target (it can be included in other shared objects as well as executables). Note that due to limitations in CMake, either a shared or a static library can be built, but not both. (This is due to the fact that on Windows, an import library has the same name as a static library).
2012-12-19 14:49:59 +01:00
# default to building a shared library, but let user override
if (DEFINED BUILD_SHARED_LIBS)
set (_shared_def ${BUILD_SHARED_LIBS})
else (DEFINED BUILD_SHARED_LIBS)
set (_shared_def ON)
endif (DEFINED BUILD_SHARED_LIBS)
option (BUILD_opm-core_SHARED "Build opm-core as a shared library" ${_shared_def})
if (BUILD_opm-core_SHARED)
set (opm-core_LIBRARY_TYPE SHARED)
else (BUILD_opm-core_SHARED)
set (opm-core_LIBRARY_TYPE STATIC)
endif (BUILD_opm-core_SHARED)
Barebones CMake configuration file
2012-11-14 12:45:48 +01:00
# create this library
include_directories (${opm-core_INCLUDE_DIRS})
Add library search directories to linker options Some older packages, and notably those that are detected by PkgConfig, only give library names and then a list of library search directories. Add to link_directories here in order to support this configuration, even though it is deprecated in newer versions of CMake.
2012-11-30 12:59:08 +01:00
link_directories (${opm-core_LIBRARY_DIRS})
Do list cleanup in find routine Although this amounts to some double work, it doesn't make the configuration noticeably slower, and it ensures that the lists are always cleaned up (in a proper way).
2012-12-11 09:30:49 +01:00
add_definitions (${opm-core_DEFINITIONS})
Make building libraries static or shared selectable Default is still to make a shared object because this is the most versatile target (it can be included in other shared objects as well as executables). Note that due to limitations in CMake, either a shared or a static library can be built, but not both. (This is due to the fact that on Windows, an import library has the same name as a static library).
2012-12-19 14:49:59 +01:00
add_library (opmcore ${opm-core_LIBRARY_TYPE} ${opmcore_SOURCES})
Rename version variables
2012-12-07 13:14:16 +01:00
set (opm-core_VERSION "${opm-core_VERSION_MAJOR}.${opm-core_VERSION_MINOR}")
Added library version
2012-11-15 11:36:50 +01:00
set_target_properties (opmcore PROPERTIES
Rename version variables
2012-12-07 13:14:16 +01:00
SOVERSION ${opm-core_VERSION_MAJOR}
VERSION ${opm-core_VERSION}
Use generic boilerplate macro to include packages
2012-11-28 10:44:54 +01:00
LINK_FLAGS "${opm-core_LINKER_FLAGS_STR}"
Added library version
2012-11-15 11:36:50 +01:00
)
Use generic boilerplate macro to include packages
2012-11-28 10:44:54 +01:00
target_link_libraries (opmcore ${opm-core_LIBRARIES})
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
Enable debugging support
2012-11-29 12:36:29 +01:00
# queue this executable to be stripped
Install debug files As part of a -dev package, we would like to install the debug symbols together with the headers.
2013-01-23 00:57:50 +01:00
strip_debug_symbols (opmcore opm-core_DEBUG)
Enable debugging support
2012-11-29 12:36:29 +01:00
Use precompiled headers to compile C++ modules On an average system this will cut around 15% of the total build time. Unfortunately, including Boost headers in the precompiled header takes longer time to generate and then read in each module, than just including the necessary headers in each module. Use Noel Llopis' list_precomp.py at http://www.gamesfromwithin.com/wp-content/uploads/bin/list_precomp_py.txt to analyse which headers are included the most and are candidates for inclusion.
2013-01-23 14:35:50 +01:00
# pre-compile common headers; this is setup *after* the library to pick
# up extra options set there
Enable opt-out of precompiled headers Some versions of the compiler are buggy, and will actually crash if precompiled headers are used. This option enable disabling the feature and building without by simply setting a command-line option.
2013-01-24 20:45:39 +01:00
option (PRECOMPILE_HEADERS "Precompile common headers for speed." ON)
mark_as_advanced (PRECOMPILE_HEADERS)
if (PRECOMPILE_HEADERS)
get_target_property (_type opmcore TYPE)
precompile_header (CXX ${_type}
HEADER "${opmcore_PRECOMP_CXX_HEADER}"
TARGET opmcore_CXX_pch
FLAGS opmcore_PRECOMP_CXX_FLAGS
)
# must set property on source files instead of entire target, because
# it only applies to C++ modules (and cannot be used for C)
set_source_files_properties (${opmcore_CXX_SOURCES} PROPERTIES
OBJECT_DEPENDS "${opmcore_CXX_pch}"
COMPILE_FLAGS "${opmcore_PRECOMP_CXX_FLAGS}"
)
message (STATUS "Precompiled headers: ${opmcore_CXX_pch}")
else (PRECOMPILE_HEADERS)
message (STATUS "Precompiled headers: disabled")
endif (PRECOMPILE_HEADERS)
Use precompiled headers to compile C++ modules On an average system this will cut around 15% of the total build time. Unfortunately, including Boost headers in the precompiled header takes longer time to generate and then read in each module, than just including the necessary headers in each module. Use Noel Llopis' list_precomp.py at http://www.gamesfromwithin.com/wp-content/uploads/bin/list_precomp_py.txt to analyse which headers are included the most and are candidates for inclusion.
2013-01-23 14:35:50 +01:00
Install the library and headers Enables running `make && make install` on a target system. Documentation is not yet built or installed.
2012-12-07 08:58:18 +01:00
### installation ###
foreach (_hdr IN LISTS opmcore_HEADERS)
get_filename_component (_dir ${_hdr} PATH)
Use relative path function instead of string manip. This rest-of-string functionality is not supported by older CMakes anyway.
2013-01-23 00:04:50 +01:00
file (RELATIVE_PATH _rel_dir "${PROJECT_SOURCE_DIR}" "${_dir}")
Install the library and headers Enables running `make && make install` on a target system. Documentation is not yet built or installed.
2012-12-07 08:58:18 +01:00
install (
FILES ${_hdr}
Use relative path function instead of string manip. This rest-of-string functionality is not supported by older CMakes anyway.
2013-01-23 00:04:50 +01:00
DESTINATION include/${_rel_dir}
Install the library and headers Enables running `make && make install` on a target system. Documentation is not yet built or installed.
2012-12-07 08:58:18 +01:00
)
endforeach (_hdr)
install (
TARGETS opmcore
Enable support for multi-arch on Debian/Ubuntu
2013-01-16 23:36:16 +01:00
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
Install the library and headers Enables running `make && make install` on a target system. Documentation is not yet built or installed.
2012-12-07 08:58:18 +01:00
)
Install .debug files in system location if writable If the installation prefix is set to /usr, then it is assumed that the user has write access to the entire of that subtree, and that it would be advantageous to put the .debug files in the /usr/lib/debug directory. This is the usual case for package installations. On the other hand, if the prefix is NOT /usr, then it is probably a local installation; someone trying to install it to a more restricted area. In that case, the default is to follow the binary, so that GDB will still pick up the .debug file when loading the shared object. In any case can this default be overridden, should it turn out that the configuration script has guessed wrongly for your needs.
2013-01-30 12:41:34 +01:00
# only /usr/lib/debug seems to be searched for debug info; if we have
# write access to that directory (package installation), then default
# to use it; otherwise put the debug files together with the library
# (local installation). everything can be overridden by the option.
if (CMAKE_INSTALL_PREFIX STREQUAL "/usr")
set (_sys_dbg_def ON)
else (CMAKE_INSTALL_PREFIX STREQUAL "/usr")
set (_sys_dbg_def OFF)
endif (CMAKE_INSTALL_PREFIX STREQUAL "/usr")
option (SYSTEM_DEBUG "Put .debug files in GDB debug file directory" ${_sys_dbg_def})
Put debug files in GDB's debug-file-directory This puts the .debug file in the separate root reserved for such, as pointed to by GDB's debug-file-directory setting, see <http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html> Notice that this is *outside* of the prefix tree!
2013-01-24 11:43:43 +01:00
set (DEBUG_FILE_DIRECTORY /usr/lib/debug CACHE LOCATION "GDB debug file directory")
mark_as_advanced (DEBUG_FILE_DIRECTORY)
Install .debug files in system location if writable If the installation prefix is set to /usr, then it is assumed that the user has write access to the entire of that subtree, and that it would be advantageous to put the .debug files in the /usr/lib/debug directory. This is the usual case for package installations. On the other hand, if the prefix is NOT /usr, then it is probably a local installation; someone trying to install it to a more restricted area. In that case, the default is to follow the binary, so that GDB will still pick up the .debug file when loading the shared object. In any case can this default be overridden, should it turn out that the configuration script has guessed wrongly for your needs.
2013-01-30 12:41:34 +01:00
if (SYSTEM_DEBUG)
set (_dbg_prefix "${DEBUG_FILE_DIRECTORY}/")
else (SYSTEM_DEBUG)
set (_dbg_prefix "")
endif (SYSTEM_DEBUG)
Only install .debug files when building shared object Static libraries usually holds the debug information together with the library because they are not loaded directly (but linked together to an executable, which can be stripped)
2013-02-01 22:02:13 +01:00
# static libraries don't have their debug info stripped, so there is
# only a separate file when we are building shared objects
if (BUILD_opm-core_SHARED)
install (
FILES ${PROJECT_BINARY_DIR}/${opm-core_DEBUG}
DESTINATION ${_dbg_prefix}${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}
)
endif (BUILD_opm-core_SHARED)
Allow system installation to be used with dunecontrol
2013-01-16 11:29:29 +01:00
install (
Revert clever setting of version number in dune.module dunecontrol will read the dune.module file first, before calling any configuration files; thus it cannot be initialized from the script but the version numbers must be hardcoded here and updated manually.
2013-01-30 14:06:05 +01:00
FILES ${PROJECT_SOURCE_DIR}/dune.module
Support arch.-indep. libraries files for 64-bit sys. Fedora uses lib64/ for architecture-independent files on 64-bit systems, whereas Debian (which is multi-arch for binaries) uses lib/
2013-01-22 11:57:10 +01:00
DESTINATION ${CMAKE_INSTALL_LIBDIR_NOARCH}/dunecontrol/opm-core
Allow system installation to be used with dunecontrol
2013-01-16 11:29:29 +01:00
)
Install the library and headers Enables running `make && make install` on a target system. Documentation is not yet built or installed.
2012-12-07 08:58:18 +01:00
message (STATUS "This build defaults to installing in ${CMAKE_INSTALL_PREFIX}")
Move writing of config module to library routine
2013-01-25 21:16:47 +01:00
# we need to know the name of the library which is generated
get_target_property (opm-core_LIBRARY opmcore LOCATION)
Install config mode CMake module at installation find_package only searches for FindXxx-modules in the path specified by CMAKE_MODULE_PATH; other paths are supposed to contain config-mode modules (much like pkgconfig). Generate the config-mode module in the installation directory using the same template as is used for the one in the build directory, only selectively swapping some directories in the relevant variables.
2012-12-07 12:18:49 +01:00
# installation of CMake modules to help user programs locate the library
include (OpmProject)
opm_cmake_config (opm-core)
Build tutorials through Makefile Newcomers may want to step through the tutorials in the debugger without creating a new project specifically for them; this enables them to do so through the regular build system. To see how a program is linked with the library, just execute make tutorials VERBOSE=1
2013-01-24 23:54:47 +01:00
### tutorials ###
# enumerate tutorials in project
file (GLOB tutorial_SOURCES "tutorials/tutorial[0-9].cpp")
# add each tutorial as a target of its own
add_custom_target (tutorials)
foreach (tutorial_FILE IN LISTS tutorial_SOURCES)
# get the name of the executable based on the source code file
get_filename_component (tutorial_NAME "${tutorial_FILE}" NAME_WE)
# setup an executable, linking to the main library
add_executable (${tutorial_NAME} EXCLUDE_FROM_ALL ${tutorial_FILE})
set_target_properties (${tutorial_NAME} PROPERTIES
LINK_FLAGS "${opm-core_LINKER_FLAGS_STR}"
)
target_link_libraries (${tutorial_NAME} opmcore ${opm-core_LIBRARIES})
strip_debug_symbols (${tutorial_NAME})
# add to list of tutorials to build
add_dependencies (tutorials ${tutorial_NAME})
endforeach (tutorial_FILE)
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
### test programs ###
Use each unit test program as a CTest test The name of the test is taken from the stem of the file; if two tests have the same name in different directories, the makefiles will get confused, so don't do that.
2013-01-24 15:07:23 +01:00
enable_testing ()
include (CTest)
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
Only build proper unit tests People are encouraged to convert the tests in not-unit/ to proper unit tests and move them back into the parent tests/ directory; they will then be picked up by the testing framework automatically.
2013-01-24 15:06:10 +01:00
# enumerate all testing programs
file (GLOB_RECURSE tests_SOURCES "tests/test_*.cpp")
file (GLOB_RECURSE not_tests_SOURCES "tests/not-unit/test_*.cpp")
list (REMOVE_ITEM tests_SOURCES ${not_tests_SOURCES})
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
Remove test when the feature is not available
2012-11-25 23:06:39 +01:00
# conditionally disable tests when features aren't available
macro (cond_disable_test name)
Don't expand variables for test Use only expansion when comparing the variable against a literal, not when comparing for logical true or if defined.
2012-12-12 22:10:32 +01:00
if ((NOT DEFINED HAVE_${name}) OR (NOT HAVE_${name}))
Remove test when the feature is not available
2012-11-25 23:06:39 +01:00
message (STATUS "${name} test disabled, since ${name} is not found.")
string (TOLOWER "${name}" name_lower)
get_filename_component (test_${name}_FILE "tests/test_${name_lower}.cpp" ABSOLUTE)
list (REMOVE_ITEM tests_SOURCES "${test_${name}_FILE}")
Don't expand variables for test Use only expansion when comparing the variable against a literal, not when comparing for logical true or if defined.
2012-12-12 22:10:32 +01:00
endif ((NOT DEFINED HAVE_${name}) OR (NOT HAVE_${name}))
Remove test when the feature is not available
2012-11-25 23:06:39 +01:00
endmacro (cond_disable_test name)
cond_disable_test ("AGMG")
cond_disable_test ("ERT")
Make datafiles from source tree available for tests The datafiles that are in the tests/ directory are copied to a corresponding location in the output tree, and the tests are then executed from this directory (i.e. their current directory is set to tests/. If a test overwrites an input file, this will not be noticed in the source tree -- but don't do that! The tests have write access to their current directory, so they can generate new files and compare them to a stored master file.
2013-01-30 10:24:20 +01:00
# if ever huge test datafiles are necessary, then change this
# into "create_symlink" (on UNIX only, apparently)
set (make_avail "copy")
# provide datafiles as inputs for the tests, by copying them
# to a tests/ directory in the output tree (if different)
set (test_INPUT_FILES)
file (GLOB test_DATA "tests/*.xml")
foreach (input_datafile IN LISTS test_DATA)
file (RELATIVE_PATH rel_datafile "${PROJECT_SOURCE_DIR}" ${input_datafile})
set (output_datafile "${PROJECT_BINARY_DIR}/${rel_datafile}")
if (NOT output_datafile STREQUAL input_datafile)
add_custom_command (
OUTPUT ${output_datafile}
COMMAND ${CMAKE_COMMAND}
ARGS -E ${make_avail} ${input_datafile} ${output_datafile}
DEPENDS ${input_datafile}
VERBATIM
)
endif (NOT output_datafile STREQUAL input_datafile)
list (APPEND test_INPUT_FILES "${output_datafile}")
endforeach (input_datafile)
add_custom_target (datafiles
DEPENDS ${test_INPUT_FILES}
COMMENT "Making test data available in output tree"
)
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
# compile each of these separately
Make datafiles from source tree available for tests The datafiles that are in the tests/ directory are copied to a corresponding location in the output tree, and the tests are then executed from this directory (i.e. their current directory is set to tests/. If a test overwrites an input file, this will not be noticed in the source tree -- but don't do that! The tests have write access to their current directory, so they can generate new files and compare them to a stored master file.
2013-01-30 10:24:20 +01:00
add_custom_target (tests DEPENDS datafiles)
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
foreach (test_FILE IN LISTS tests_SOURCES)
get_filename_component (test_NAME "${test_FILE}" NAME_WE)
Build tests as a separate target It is very annoying having to build all the tests when you are testing some code in the main library. Someone downloading the library probably doesn't need the tests either, so these are left out of the default target.
2013-01-10 12:58:52 +01:00
add_executable (${test_NAME} EXCLUDE_FROM_ALL ${test_FILE})
add_dependencies (tests ${test_NAME})
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
set_target_properties (${test_NAME} PROPERTIES
LINK_FLAGS "${opm-core_LINKER_FLAGS_STR}"
)
target_link_libraries (${test_NAME} opmcore ${opm-core_LIBRARIES})
Don't strip debug symbols from libraries Infer the type of library from the target and only activate debug symbol stripping if it is an executable format. Note that this changes the signature of the strip_debug_symbols macro.
2012-12-19 14:39:45 +01:00
strip_debug_symbols (${test_NAME})
Use each unit test program as a CTest test The name of the test is taken from the stem of the file; if two tests have the same name in different directories, the makefiles will get confused, so don't do that.
2013-01-24 15:07:23 +01:00
string (REGEX REPLACE "^test_([^/]*)$" "\\1" test_FANCY "${test_NAME}")
get_target_property (test_LOC ${test_NAME} LOCATION)
add_test (${test_FANCY} ${test_LOC})
Make datafiles from source tree available for tests The datafiles that are in the tests/ directory are copied to a corresponding location in the output tree, and the tests are then executed from this directory (i.e. their current directory is set to tests/. If a test overwrites an input file, this will not be noticed in the source tree -- but don't do that! The tests have write access to their current directory, so they can generate new files and compare them to a stored master file.
2013-01-30 10:24:20 +01:00
# run the test in the directory where the data files are
set_tests_properties (${test_FANCY} PROPERTIES
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/tests
)
Compile programs in the tests/ directory
2012-11-25 23:05:57 +01:00
endforeach (test_FILE)
Generate customized Doxyfile for each build
2012-12-20 14:41:18 +01:00
Add target to run self-tests `make check` is run by the Debian package creator, so it must be a supported target in the Makefile. For now this is just the same as `make tests`, but in the future we may/should/must expand this to also run the tests and figure out if the output is OK (whereas `make tests` will continue to only compile them)
2013-01-18 09:14:53 +01:00
# ideally this should run the tests, but for now we only test if they
# compile without errors
add_custom_target (check
Run unit tests when doing `make check'
2013-01-24 19:44:09 +01:00
COMMAND ${CMAKE_CTEST_COMMAND}
Add target to run self-tests `make check` is run by the Debian package creator, so it must be a supported target in the Makefile. For now this is just the same as `make tests`, but in the future we may/should/must expand this to also run the tests and figure out if the output is OK (whereas `make tests` will continue to only compile them)
2013-01-18 09:14:53 +01:00
DEPENDS tests
COMMENT Checking if library is functional
VERBATIM
)
Generate customized Doxyfile for each build
2012-12-20 14:41:18 +01:00
### documentation ###
configure_file (
${PROJECT_SOURCE_DIR}/Doxyfile.in
${PROJECT_BINARY_DIR}/Doxyfile
@ONLY
)
Generate documentation in a custom target The targets are named after the similar targets when using Autotools.
2012-12-20 15:06:02 +01:00
find_package (Doxygen)
if (DOXYGEN_FOUND)
add_custom_target (doc
COMMAND ${DOXYGEN_EXECUTABLE} ${PROJECT_BINARY_DIR}/Doxyfile
SOURCES ${PROJECT_BINARY_DIR}/Doxyfile
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
COMMENT "Generating API documentation with Doxygen"
VERBATIM
)
Disable generation of LaTeX/PDF documentation Class listings are impractical in PDF format. Instead, the tutorial alone could perhaps be published in PDF.
2013-01-22 12:27:39 +01:00
set (_formats html)
Make documentation installable If `make install` is run, the document is included if and only if it has already been built. If `make install-html` is run, then the documentation is always generated first, before installation. To build the documentation separately from installation use `make doc`
2012-12-20 23:41:58 +01:00
foreach (format IN LISTS _formats)
string (TOUPPER ${format} FORMAT)
install (
DIRECTORY ${PROJECT_BINARY_DIR}/Documentation/${format}
DESTINATION share/doc/opm-core/
COMPONENT ${format}
OPTIONAL
)
# target to install just HTML documentation
add_custom_target (install-${format}
COMMAND ${CMAKE_COMMAND} -DCOMPONENT=${format} -P cmake_install.cmake
COMMENT Installing ${FORMAT} documentation
VERBATIM
)
# since the documentation is optional, it is not automatically built
add_dependencies (install-${format} doc)
endforeach (format)
Generate documentation in a custom target The targets are named after the similar targets when using Autotools.
2012-12-20 15:06:02 +01:00
endif (DOXYGEN_FOUND)
Provide distclean target to remove CMake artifacts If you are building in-tree (which is commonly done by dunecontrol), it can be advantageous to have a target which is capable of cleaning out all the files that CMake left without having to erase the entire folder.
2013-01-09 09:37:57 +01:00
### clean in-source builds ###
set (DISTCLEAN_FILES
CMakeCache.txt
cmake_install.cmake
Makefile
config.h
opm-core-config.cmake
opm-core-config-version.cmake
opm-core-install.cmake
Doxyfile
)
set (DISTCLEAN_DIRS
CMakeFiles/
)
add_custom_target (distclean
COMMAND ${CMAKE_COMMAND} -E remove ${DISTCLEAN_FILES}
COMMAND ${CMAKE_COMMAND} -E remove_directory ${DISTCLEAN_DIRS}
# cannot depend on clean because it is only defined in the master Makefile
# not in CMakeFiles/Makefile where this target will end up
# DEPENDS clean
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
COMMENT Removing CMake-generated files
VERBATIM
)
Replace build script with a smart wrapper If a user simply types `make` it will run in parallel by default, which is what we want to do in most cases.
2013-01-17 14:52:35 +01:00
# smart wrapper that auto-parallelizes builds
file (COPY
GNUmakefile
DESTINATION ${PROJECT_BINARY_DIR}
)
Enable building as a link in dunecontrol chain Dunecontrol scans the module directory for certain files and phrases which must be present if the project can be used as a dependency for other DUNE modules.
2013-02-01 13:10:20 +01:00
# provide compatibility with using this build in dunecontrol
include (DuneCompat)
Reference in New Issue Copy Permalink