Previously, touching CMakeLists.txt after a first compilation would
trigger compile errors as the two CMake runs were done with
inconsistent parameters (first one without USE_SUPERLU defined and
second one with -DUSE_SUPERLU=ON). Of course that meant that the
options would also differ from module to module, which seems like a
recipe for desaster.
This patch fixes this by moving the definition of the USE_SUPERLU
option to OpmInit.cmake which is included very early in the top most
CMakeLists.txt of each module.
ClosesOPM/opm-simulators#3908
Uses GNUInstallDIrs' CMAKE_INSTALL_DATAROOTDIR as top directory for
common python scripts. Also adds that location to
opm-project-config.cmake.in such that other opm modules can
easily lookup the common scripts
Adds a method get_injection_properties() to the Python interface to
Opm::Schedule. This method can be used to get information about
Well::WellInjectionProperties for a given report step.
In order to avoid code duplication between opm-simulators and opm-common,
logic in CMakeLists.txt was refactored out into
cmake/Modules/PyInstallPrefix.cmake
We usually list all libraries that might be needed for linking in the
CMake package configuration files. This is needed when building static
libraries as we do not yet use CMake targets (which would allow to
list them differently). As we are doing this unconditionally and
also including the ones listed in modules that we depend on, changing
a library (e.g. moving from Python 3.9 to 3.10) requires a complete
rebuild of all modules to get rid of the stale dependency on
libpython3.9.
At least when building shared libraries listing the dependencies is
not needed and this patch simply removes all shared libraries form the
list in the CMake package configuration file. Thus we only need to
recompile the modules that have direct dependency on a stale library.
Quadmath is usually unused except when a dependency uses it and
explicitly puts QuadMath::QuadMath into their CMake package
configuration file.
On most platforms the compiler has Quadmath available by
default. But on those that don't we should not stop CMake and fail.
Hence now we only print a message that Quadmath is not available.
Concerning MPI, both DUNE and OPM must be compiled with the
same default. For DUNE that is to used MPI if it is found.
With the previous default Cmake in opm-grid would fail for
DUNE 2.8
Even if SuperLU is found umfpack will be used as the coarse
solver for AMG. But if dune-fem is used that will need SuperL
if it is on the system otherwise linking will fail for DUNE 2.8
Quadmath is used by dune-fem if it is found and linking of flow
will fail in this case for DUNE 2.8 if we did not search for it.
One can now set the variable OPM_BINARY_PACKAGE_VERSION to a
meaningful version string (Debian 11.2: 2021.10-4). When building
outside of git it will be used as the project hash. If the variable is
non-empty there will also be no timestamp in project-timestamp.hh (as
this would break reproducible builds).
Note that if building from git or not setting the variable then everything
will be like before.
This hides them for shared libraries that do not need them.
Should fix the following lintian warnings:
W: libopm-common-dev: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/opm-common.pc -lpython3.7m (line 12)
W: libopm-common-dev: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/opm-common.pc -lstdc++fs (line 12)
W: libopm-common-dev: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/opm-common.pc -lgomp (line 12)
W: libopm-common-dev: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/opm-common.pc -lboost_system (line 12)
W: libopm-common-dev: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/opm-common.pc -lcjson (line 12)
Gbp-Pq: Name 0002-List-link-dependencies-as-private.patch
Fixes errors like
Target "test_communication_utils" links to target
"PkgConfig::PkgConfigTBB" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
When configured with TBB dune-common-targets.cmake lists the
imported TBB::tbb or PkgConfig::PkgConfigTBB target
in INTERFACE_LINK_LIBRARIES. Hence we need to be able to resolve
this target in opm. We do this by searching for TBB id dune-common
is a prerequisite.
This commit fixes the problem only for newer versions of TBB shipping a
TBBConfig.cmake file.
The error fixed is along these lines:
Target "test_communication_utils" links to target "TBB::tbb" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
With version 2.8 DUNE will specify imported target METIS::METIS for
the linker and introduces a METIS_API_VERSION to distinguish different
versions. This patch introduces these to the find module used by OPM.
With that combination the first search seems to happen in CONFIG mode
but subsequent searches will use MODULE mode. This will result in the
following warning:
CMake Warning at /usr/share/cmake-3.18/Modules/FindBoost.cmake:1187 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
Call Stack (most recent call first):
/usr/share/cmake-3.18/Modules/FindBoost.cmake:1311 (_Boost_COMPONENT_DEPENDENCIES)
/usr/share/cmake-3.18/Modules/FindBoost.cmake:1919 (_Boost_MISSING_DEPENDENCIES)
cmake/Modules/OpmFind.cmake:135 (find_package)
cmake/Modules/OpmFind.cmake:230 (find_and_append_package_to)
cmake/Modules/OpmLibMain.cmake:83 (find_and_append_package_list_to)
CMakeLists.txt:222 (include)
Also the variable Boost_LIBRARIES will look quite messed up by
occurrences of optimized and debug:
Boost_LIBRARIES=optimized;/usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0;debug;/usr/lib/x86_64-linux-gnu/libboost_system.so;optimized;/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so.1.74.0;debug;/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so
Which will make the modules unusable because of CMake errors during
linking:
CMake Error at /usr/share/dune/cmake/modules/DuneMacros.cmake:991 (target_link_libraries):
The "debug" argument must be followed by a library.
Call Stack (most recent call first):
src/CMakeLists.txt:2 (target_link_dune_default_libraries)
-- Configuring incomplete, errors occurred!
Note this fix is only needed for Boost versions 1.70 and higher.
Older versions do not provide cmake package configuration
files (BoostConfig.cmake) and hence there can be no mixup.
Note also that the alternative approach of setting
CMAKE_FIND_PACKAGE_PREFER_CONFIG does not work for OPM as with this
e.g. the Dune module versions would not be set correctly.
That location is /usr/share/bash-completion/completions and scripts
will be loaded on demand. Added option USE_BASH_COMPLETIONS_DIR (default OFF)
to request this. It is needed to prevent lintian warnings for Debian
packages.
OpmPackage is needed as it defines find_package_deps. The CXX standard
needs to be set as some cmake package config scripts will add
incompatible compile switches like -std=gnu++11 otherwise (I guess
because of import targets with INTERFACE_COMPILE_FEATURES), that will
break the build.
We actually already require at least CMake 2.8.12 due to the embedded
pybind11 (some tests of it are even at 3.0). Anyway as Ubuntu LTS has
3.10.2 I doubt that anything less is tested by us.
Previously we ended up with "-I -I/cjson" for
"/usr/include;/usr/include/cjson" in opm-common_INCLUDE_DIRS.
Gbp-Pq: Name 0008-Fixes-include-paths-in-pkg-config-files-at-least-in-.patch
Previously the SOVERSION was the year which indicated a stable ABI
within each year. It is highly unlikely that or ABI is that
stable. Hence we stop pretending that it is and change the version
with every release.
Gbp-Pq: Name 0006-Make-SOVERSION-change-with-every-release.patch
They had imported target names (e.g. from OpenMP) in them which did not work.
Also linking std++fs was a bit strange. Hopefully fixed now.
Gbp-Pq: Name 0003-Fix-pkg-config-files-with-imported-targets.patch
add_definitions is deprecated.
Note the new command does not need the -D qualifier but will detect
if there is one and act accordingly. This helps with package
configuration files that have "-DVAR" in their COMPILE_DEFINTIONS
As some packages actually already add the -D qualifier we now detect
that to be able to support old CMake version without
add_compile_definitions. In this case we prevent adding another -D
and use add_definitions.
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.
