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.
When specifying NO_DEFAULT_PATH, we have to specify include and lib
manually to find the headers and libraries. This commit does this
for FindParMETIS and FindPTScotch
Previously we added (PAR)METIS_INCLUDE_DIRS to CMAKE_REQUIRED_INCLUDES
even if these directories were not found and set to
(PAR)METIS_INCLUDE_DIR-NOTFOUND. Now we test whether they are found and only
use them in this case.
- Using standard python 'import ert' and introspection.
- Using dist-packages (debian) and site-packages (!debian).
- In separate cmake module FindERTPython.cmake
for me, 4292de413f lead to linker errors
if the sequential metis library was required (and the parallel is not
installed). see e.g.,
http://www.opm-project.org/CDash/viewBuildError.php?buildid=41290
The reason for this is a partial clash in the variable names which are
used by both modules. With this PR, the FindParMETIS module does not
write to any variables that are prefixed by "METIS_".
if the 'configure' wrapper is used, you will most likely use
dunecontrol. since duncontrol explicitly passes the paths for all the
dependencies, the "convenience" of the sibling search not wanted in
most cases.
The AMG within dune-istl issues a warning if ParMETIS is not available.
The reason is that it uses ParMETIS or the ParMETIS bindings of PT-Scotch
to redistribute the load on the coarse levels. Even with an installed and
found PT-Scotch we need to adapt the include path and the libraries linked
to make it work.
Therefore this commit adds a module for searching for ParMETIS and activates
it whenever dune-istl is a dependency. With this the warning about missing
ParMETIS for flow_cp vanishes.
- pass on toolchain file
- don't build examples in static directories
- allow non-install mode and custom targets in opm_from_git
- use origin/master to make sure static source trees are built from the
top should user re-execute the build in an existing build tree
