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.
Some configuration scripts probe and just set HAVE_FOO without any
values, whereas others set it explicitly to 1. If these two are mixed,
for instance that the same package is used by two of our prerequisites,
but in different manner, then we get compatibility warnings when we try
to run the configuration script, even though there is no real conflict.
dune-fem, dune-alugrid and dune-localfunctions have this problem (around
release 2018.04).
This patch special-code the test so if the old value was previously
either just defined or explicitly set to the value 1, a warning will not
be issued if then suddenly the other variant is used.
Otherwise we will never search for e.g. Boost multiple
times and the upmost module in the hierarchy will dictate
the components to be used. That does not work for downstream
modules.
Therefore with this change we check whether there is an argument
COMPONENTS passed to find_package and make sure there will be
another call to it if that is the case.
The code in @opm-project_NAME@-prereqs uses macros from OpmPackage.cmake. At
the previous location that file was not yet included for the module opm-common
as this is done in the section @OPM_PROJECT_EXTRA_CODE@, which also sets
CMAKE_MODULE_PATH.
Libtool uses libtool archive files (.la) to determine how to do a
platform-specific link. To generate these files, it is necessary to have
libtool installed on the system, since it will only accept files with
its own particular version number embedded. If libtool is not installed,
you probably don't need the libtool archive files either, so no .la is
generated. However, the status message sounded like libtool was probed
but not found, and that this was something that you should install.
This patch modifies the status message to make it more clear way libtool
was probed, and what the consequence of a missing libtool is (i.e. no
.la file for you).
is a shared library
additional condition for opm-parser as it forces dyn boost test (not
strictly necessary but it highlights the different behaviour for now)
