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
These take precendence over the package registry where we have no control
on which entry will be used. The registry is only the last resort.
On some Linux version the most recently created package registry key will
be used. Please not that an entry is only created for a build try that is
not already in the registry. If there is already key, then not even the
modification date of the key will be updated. This default behaviour might
lead to strange mixes of build configurations.
CONFIG mode is usually a fallback when Find* modules are not found, but
opm-parser is now mainly meant to be used with config mode, so it's the
first thing being tried. If that fails, continue with the old logic.
Some legacy requires HAVE_ERT being set somewhere, so this logic is
injected here.
Previously, this failed if one dependency was a static library compiled
without -fPIC. This is is the case for library libsuitesparseconfig on
Debian which has no dynamic alternative. The error messages read e.g.
```
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libsuitesparseconfig.a(SuiteSparse_config.o): relocation R_X86_64_PC32 against undefined symbol `malloc@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
```
With this patch we change the target_link_libraries call when using
BUILD_SHARED_LIBS=ON. We only pass the dynamic libraries as PUBLIC such
that they will get linked to the library. The static ones are passed as
INTERFACE libraries. This means that they will be automatically linked
to executables which link to the main library. Currently this transitive
linking will only work in the same module as we do not correctly export
libraries. But our build system explicitly links the others ones anyway.
Otherwise we are running into weired problems as downstream modules
refuse to set the version information correctly. This leads to
unset DUNE_MODULE_VERSION_{MINOR,MAJOR,REVISION} in config.h.
This only happened for dune-istl which was first requested by opm-core
but that module did not set the version information. Opm-grid requested
it, too. But this time this information was not correctly put into
opm-grid-config.cmake leading to erroneous checks like:
if (DEFINED DUNE_ISTL_VERSION_MAJOR AND NOT "${DUNE_ISTL_VERSION_MAJOR}" STREQUAL "")
message (WARNING "Incompatible value \"${DUNE_ISTL_VERSION_MAJOR}\" of variable \"DUNE_ISTL_VERSION_MAJOR\"")
endif ()
Note there should have been a number instead of an empty string. The version
numbers were also undefined in config.h of opm-grid. Same picture for opm-simulators.
My assumption is that for these modules Finddune-istl.cmake was implicitly included
when searching for opm-core. That module sets the version in the parent scope only
which might cause this problem. I am not sure though.
With this commit the version is always added to CONFIG_VARS for the first most upstream
OPM module that requests a dune module. This fixes the issue at least for me on my system.
Also note that this problem did not occur in all configurations. I experienced breaking
builds with the installed dune module 2.4.1 of Debian backports while using dunecontrol.
The warnings about unmatching versions happened with uninstalled 2.3, too.
