Headers from other libraries (notably DUNE) require definitions of
other variables than our probe process set (e.g. HAVE_UMFPACK instead
of HAVE_SUITESPARSE_UMFPACK_H). This module sets those aliases for
compatibility.
During configuration some of the values for CMake properties (compiler
flags etc.) may be changed either by the user (through command line
parameters or option files), or by the configuration script itself
(setting more aggressive options or detailed debugging for instance).
This change writes many of the relevant values back into the cache so
they are available for introspection (using e.g. ccmake) or when the
rerunning the configuration without specifying all options.
By using a separate variable for this we can easily grep for where
the build system depends on its own location, and also change the
policy regarding this later.
Note that there is no opm-macros module; this is a "psuedo"-module
which links to an additional one (currently, the one we're in)
This define is used by the unit tests; there is no reason why it should
be on the list that must be provided by other projects that use our
headers (the other projects don't use our tests).
This hook together with the bundled convenience macro makes it
possible to add the version of another module to config.h using
code like this:
macro (config_hook)
opm_need_version_of ("dune-common")
endmacro (config_hook)
The config variables in _CONFIG_IMPL_VARS are only written to config.h
and not the .pc or -config.cmake files. They can thus only be used by
the implementation files and not the headers. Use this set to avoid
exposing the variables to other projects, when it is likely that a
probe used by that other project may turn up a different result.
Akin to config.h, we write project-version.h whenever the VCS sha hash
of the project changes. This file can then be included to embed this
into the project. Since this changes more frequently, we choose another
file than config.h. Care is also taken to not rewrite the header if the
information doesn't change, but the project is rebuilt.
It is only used in one place, where it can easily be replaced by its
expansion. The reason for removing it is that it depends on the name
of the project, and I intend to read this using a routine it the very
directory it is including, hence the need for a different approach.
Developers that are working to familiarize themselves with OPM will
probably start out in CMakeLists.txt to figure out where the project
declare its dependencies, thus the list should be referred to from
there instead of inside one of the sub-modules.
The hooks are meant to be project specific, and should therefore
either know their own name or at least have access to a variable with
that name in it.
Andreas Lauser
Arne Morten Kvarving
Roland Kaufmann
Bård Skaflestad