Currently opm-parser does not create opm-parser-config.cmake files. Therefore
building with duncontrol fails as it sets opm-parser_DIR. With this patch
we force CMake to always use module mode for finding which fixes this.
this prevents to check for the same module more than once in the same
cmake run and should thus speed things up a bit as well as make the
output a bit cleaner. For this I assumed that the ${name}_FOUND cmake
variable does not get cached, which it seems like it does not...
Setting CMAKE_DISABLE_FIND_PACKAGE_xxx flag should make find_package
not doing anything, but this does not seem to work with older versions
of CMake. Anyway, we can test this flag and make sure that we don't
call find_package in that case.
Also includes a check for both upper- and same-case versions of found
flag, as some modules, most notably Boost, does not set the upper-case
version of their _FOUND flag; this tests for both.
If it is already found, most packages sets a flag that makes it exit
immediately anyway. We usually cannot rerun find_package to get another
combinations of modules. Here we check the flag before we start looking
for the package to avoid the endless stream of messages.
Resurrect support for AGMG library
This is an interim milestone that may serve as point from which to
resurrect the AGMG suppert fully if the AGMG author ever decides to
re-release the software under an open licence.
By returning a ${package}_SOURCES variable with the names of the code,
it will be propagated to ${project}_SOURCES and subsequently compiled
into the library.
AGMG (Algebraic Multigrid) uses this functionality.
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.
In CMake "canon" (i.e. tutorial on Kitware's website) it is stated that
the _DIR suffix should be used for the directory of the library alone,
whereas _DIRS are entire list of paths necessary to compile (i.e.
dependencies are included).
Eigen3 only uses the singular form (since it doesn't have any
dependencies); it should really be copied to the plural form, but it may
be advantageous to have the find-module included unchanged, so we put in
an extra effort to find it here.
Instead of having to specify each and every project in a suite such as
DUNE or OPM, allow a root directory for the entire suite to be specified
and then assume that each module is located in a sub-directory to this.
Each individual project can still have its path explicitly specified, if
a special build of those are required.
The suite variable itself will be written to cache by being specified
on the command line. Each individual project directory will NOT be
written to cache, because then we cannot get rid of it by specifying a
new suite directory.
Commit b6cdc06b introduced heuristics to look in the parent directory
for header files alone, while leaving the path for binary files. This
is much better than adjusting the path because one does not potentially
confuse two build directories this way.
If we give an explicit directory path it is because we want a special
version to be used instead of the system version; if there is any
problems with that, we should know up-front instead of silently start
using the system version again!
Some libraries require more information than what is present in the
xxx-config.cmake file, e.g. the caller must know whether HAVE_TUPLE
is available and probably used when compiling dune-common, and put
this in its own config.h file.
Code to take care of these variables must therefore be in the client
configuration, and this is the same code which is used to handle the
autotools version, namely the find module, so a practical solution
is to just revert to that in both cases.
For compatibility with packages that believes that every variable
should be in uppercase, we try this variant when adding relevant
variables to the project.
There were (at least) three implementations of the same macro; these
have been collected into a separate helper module. (Note that this
means that FindERT is now not completely stand-alone anymore).
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).
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.
Markus Blatt
Andreas Lauser
Roland Kaufmann
Bård Skaflestad