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)
earlier the assumption has been that all test executables have a test_ prefix
which was stripped off. now we just use the full name if the prefix is not
found.
Otherwise implicit dependencies are never search for. That was the case
for dune-geometry and dune-grid when configuring opm-core as these are only
transitively required via opm-grid.
With this commit we include <module>-prereqs.cmake in <module>-config.cmake
and thus trigger searches for all modules that this module depends on.
We also install the file now <module>-prereqs.cmake as we need it for
installed modules, too.
use pure config mode.
we no longer compile a test application for the libraries,
however checks have been tightened by making sure version of
all opm modules are the same.
this allows for putting prereqs directly in the module repositories
this used to provide autotools compatibility, but it has not been working for a while. Thus it is IMO better to remove it in order not to mislead people.
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
Previously, we checked for header CpGrid.hpp which finally
tried to include the non-existent generic geometry headers
as the checks for dune-geometry versions do not work during
a CMake run.
With this patch we search for the header GlobalIdMapper.hpp which
does not use any version checks and therefore works for every DUNE
version.
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.
