before OPM/opm-simulators#1309 it was required, but this was not
enforced by the build system because the SuiteSparse tests are run by
the opm-core build system first and UMFpack is optional there.
thanks to [at]akva2 and [at]blattms for the heads-up.
Since all supported DUNE versions have a CMake based build system,
when can drop the magic and use the module version exported by CMake
directly.
The magic used previously was broken when setting CMAKE_INSTALL_LIBDIR to
an absolute path.
As opm-common is search in the toplevel CMakeLists.txt of each module in
config mode and the dependencies and defines are only processed in
opm_find_package(opm-common), we allow a second search using module mode
to trigger opm_find_package.
Otherwise some defines and macros will not be set as this is done
in opm_find_package. This might also make sense for dunecontrol
which always will set *_DIR.
Theses variables are already set in opm-output-config.cmake. Unfortunately,
theres is still a bug there which will be fixed by a PR in opm-output. After
that everything should work and have less guess work in it.
Previously we assumed it to be ecl (like the project name).
That is not correct. With this commit we now use the correct
default clone directory, libecl, in the sibling search.
Even though people are telling that ecl is already found using
sibling search it turned out that this statement is false. It
was always found using the CMake package cache. When installing
this lead to the installed package using ecl from the build tree.
With this commit we first try to find ecl without the package cache
but maybe using sibling search. Building installed packages no works
by setting -DSIBLING_SEARCH=Off -DCMAKE_INSTALL_PREFIX=/install/path
We use ${module}_DIR to set the correct path when sibling search is activated.
The package configuration files set all the necessary variable and we save
us a lot of CMake magic.
make this default to off.
additionally, check that the found superlu version
is compatible with the dune-istl version in use.
in particular superlu5 is not compatible with dune-istl 2.4
It seems like OPM support for Dune 2.3 is going to be removed sooner
rather than later. Also, all relevant distributions which I'm aware of
seem to ship at least Dune-2.4 packages.
note that this patch switches to Dune 2.4.1 instead of the latest Dune
2.4 release (i.e., 2.4.2) because travis seems to block downloads from
sites it does not know -- in this case dune-project.org -- and the
Dune github mirrors seem to have been abandoned a few months ago and
thus do not feature dune 2.4.2.