The parmetis.h distributed via the parmetis binding of scotch
with Ubuntu 18.04 (libscotchparmetis-dev) includes the header
scotch.h located in /usr/include/scotch/. Therefore our check
of the include file failed. With this commit we check the
parmetis.h header another time with the scotch include path added.
Now parmetis is found on my Ubuntu.
When using CMAKE_DISABLE_FIND_PACKAGE_<name>=ON for a required package
CMake did not issue an errors since we never trigger the find_package
call. With this commit we now check whether such package is required
and send an error.
Otherwise we experience compilation errors if OPM is configured with
deactivated MPI and activated and found dune-alugrid (cpmpile error
that mpi.h is not found). This commit fixes this for me.
This should allow downstream to automatically use the correct
compile and linke flags for CMake > 3.9. For older versions
we fall back to the old approach.
Closes#1751
OpmInit.cmake is one of the first includes and most importantly before
the opm-*-prereqs.cmake files are include. The macro is needed to make
the policies set in all CMakefiles. OpmSetPolicies should be called in
the toplevel CMakeLists.txt file.
This fixes a lot of warnings experienced in downstream modules that
got triggered by the opm-*-prereqs.cmake files. At some calls the
policies were at other not.
On the other hand new warnings about soon to be deprecated policies
CMP0026 and CMP0048 appear at least for cmake version 3.13.4.
But that should be fixed in another PR.
when using clang, whether or not we should link to stdc++fs
cannot easily be detected. it depends on the c++ lib used
(libstdc++ vs libc++), as well as the versions of these.
to avoid messing up in general, this adds an option for forcing
linking to stdc++fs, even when using clang. it defaults to false
to not break existing build setups where it works. is required
for building on jenkins
since we still support g++-7, where filesystem is marked experimental,
we introduce a wrapper header and expose the namespace to use
as Opm::filesystem.
for gcc we unconditionally link with libstdc++fs in the python bindings.
the setup.py stuff links as c code, not c++ code, so it is not
automatically added on any gcc version. this might prove unportable
later.
If you set CMAKE_INSTALL_PREFIX, have the dependencies installed there, but
the source of them lying around in the parent directory of the build
directory, then the build will fail starting with opm-models because
we assume that ../opm-material is a build directory and set opm-material_DIR
to it. CMake will complain about not finding opm-material-config.cmake or
Opm-materialConfig.cmake. With this commit we will only set opm-material_DIR
if the directory contains a file CMakeCache.txt (which should be the case in
a configured build directory.
Directory outline of the failing situation is
- ${CMAKE_INSTALL_PREFIX} # where all dependencies are installed
- parent_dir
|____ opm-common #source dir
|____ opm-material #source dir
|____ ...
|____ build #build directory for current module (e.g. opm-modules)
Change is tested with sibling build
- build
|___ opm-common #build dir
|___ opm-material #build dir
|___ ...
and the dune version of it
- parent_dir
|___ opm-common # source dir
|____ build # build dir opm-common
|___ opm-material # source dir
|____ build # build dir opm-material
...
We do not use it in OPM, but for whatever reason I was experiencing
linker errors (unresolved symbol) when compiling ebos with DUNE 2.6
and g++-8.2. dune-grid exports its alberta wrapper libraries in dune-grid_LIBRARIES. Previously this did not pose a problem. Somehow it does now. If
I strip the libraries from the linker line everything is fine but this
is not a good solution.
Therefore I have added a test for Alberta that is triggered by the test of
dune-grid.
