The main reason for this is that it is good style to add HAVE_FOO
config.h variables for everything which was discovered, but it also
turns out that dune-fem is quite picky about the macros which
expects (and I recently fell on my nose because of this)...
Previously, cmake succeeded even if opm-core or opm-common was not found.
The cause for this was that dune-cornerpoint was searched for first. As
it was not required it seems like opm-common and opm-core were treated as
optional too.
This commit moves the opm modules to the opm section of the variable and
changes the order of the modules such that modules listed first do not
depend on modules listed afterwards. Now cmake fails if it cannot finy any
of the required modules.
as far as I can see, it is not used in any module except opm-upscaling
and it caused the configure stage to fail if I tried to use with a
self-compiled boost 1.60 (which I have to do in order to use clang on
any modern linux distribution.)
newer versions of cmake (mine is 3.2.2) complain about policy CMP00054:
```
CMake Warning (dev) at /home/and/src/opm-common/cmake/Modules/ConfigVars.cmake:30 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted variables like "FILE" will no longer be dereferenced when the policy
is set to NEW. Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
/home/and/src/opm-common/cmake/Modules/OpmLibMain.cmake:173 (configure_vars)
CMakeLists.txt:109 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
```
since I'm pretty sure that the old behaviour was not intended here,
fix this for older versions of cmake as well (by adding a prefix so that
CMake does not interpret "FILE" as a variable.)
The changes are:
- Add new macros PROJECT_VERSION_NAME and PROJECT_VERSION_HASH
in addition to the existing PROJECT_VERSION.
- Add header include guards.
This caused trouble when the PROJECT_SOURCE_DIR is a
symlink. When 'b' is a symlink, 'a/b/../' is not the same as 'a',
but that is exactly what REALPATH does. In this case, it means that
the opm-data is found (at ../ relative to the symlink), but the path
that is set does not point to it.
After moving the headers to enable and disable external warnings to
opm-common, opm-common has become a required dependency for
dune-cornerpoint, opm-autodiff and opm-core.
Commit f638ee8 contained a last-minute, untested change that caused
downstream build failures. Reference the correct variable,
PROJECT_SOURCE_DIR
in place of the non-existent CMAKE_PROJECT_SOURCE_DIR.
Pointy hat: Bard.Skaflestad@sintef.no
This is a work-around for an issue that presented when switching
module opm-material's test framework to using the opm_add_test macro
with automatically detected sources. The macro would not find any
source files and subsequently end up effectively calling
add_executable("${CURTEST_EXE_NAME}")
which promts CMake to respond with "incorrect number of parameters".
There may be other, more fundamental, problems here, but this does
at least restore the build of module opm-material on the Jenkins CI
system.
