If one sets the variable foo_DIR it will cause CMake to look for a
configuration file in that directory. In case we want to set the root
directory to an installation which doesn't have a config-mode CMake
module, and use the find module provided by ourself, we need a separate
variable that can hold the location of this directory and the most
common suffix for this seems to be _ROOT (an alternative is _PREFIX)
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.
CMake has a similar set of macros to FC_FUNC, but they of course use
another name. It also blatantly writes these macros to its own file,
overwriting anything else there (!).
This wrapper provides the same FC_FUNC interface as Autotools would
do, thus requiring no source changes.
CMake files are in general not portable between systems anyway, so we
may as well take full advantage of the native instruction set.
There must be a companion option to switch this off in case anyone
wants to build a package for distribution.
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).
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.
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.
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.
Allow arguments to be used on the list of dependencies, this facilitates
searching for things like e.g. Boost, and there is now only need for one
list since REQUIRED can be one of the arguments.
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.
If the library is not found, we will now get a message that the test
program failed to link because of a missing symbol, instead of an error
message from CMake that we tried to add -NOTFOUND libraries.
CMAKE_REQUIRED_FLAGS is intended to be added only to the compile for the
next probe, and inside an cmake_push_check_state/cmake_pop_check_state
guard. If we add it to the main flags (CMAKE_CXX_FLAGS), it will also be
added to subsequent checks, so it suffices.
If the package is installed at system standard location (such as
/usr or /usr/local), the headers will be located in the include
subdirectory and not under the root.
This find module is provided to help user programs locate an opm-core
library installation on their system; it is not used by opm-core itself.
Note that it has a direct dependency on the UseOpmFind and UseOpmPackage
helper modules; these must be in the CMAKE_MODULE_PATH also.
Instead of adding a package's standard variables to the project, it may
be desirable to be able to specify the prefix of the variables to add
them to, so the macro find_and_append can also be used in find modules.
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.
Always include debug symbols in the build, and strip them to a separate
file after compiling. The GNU debugger will automatically pick up the
external debug symbols due to a link we put in the executable.
Having debug symbols do not affect the level of optimization in the GNU
toolchain.
Search for known headers and library files that indicates that DUNE is
available on the system, and setup compiler and linker variables.
Unfortunately, this module has hard-coded some knowledge of the
dependencies on other modules, and knowledge of which symbols that
should be defined. This information must be revised whenever a new
version of DUNE is released, because it is hard and error-prone to
infer this automatically.
As for the name of the modules, see the comment by mblatt at 2012-05-22
in the thread about CMake evaluation in the DUNE user forum:
<http://www.dune-project.org/flyspray/index.php?do=details&task_id=1000>
Search for modules in this library in the same style as Boost; by
specifying a list of components. If all on the list is present, then
a list of libraries to link with, is returned.
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.
Normally a package returns a set of standard variables such as
Xxx_INCLUDE_DIRS. Adding this to a list that is collected for the
project amounts to a bunch of boilerplate which can rather be
encapsulated in a macro.
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.
A fundamental problem with the configure_file() command is CMake is that
the author of the template file config.h.in must know which variables
all modules need to have defined, and this is not easily communicated.
The idea behind this function is: Each Find-module can return a list of
variables that it has filled with probed values, and that should be
written to config.h, which is again included by the header file of this
module.
Each project thus defines its own config.h file, which is common between
all module's headers.
