I ran into problems (syntax errors in if statements) if that module
bailed out before find_package_handle_standard_args() was
invoked. Since OPM/ewoms#54 this happened e.g. on systems where no
BLAS library is installed.
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.
