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.
Otherwise the scripts will not be executable.
Fixes lintian warning
script-not-executable usr/share/opm/cmake/Scripts/cppcheck-test.sh
Gbp-Pq: Name 0007-Install-CMake-files-below-share-opm-with-USE_SOURCE_.patch
Debian policy says that each executable should have a man page.
This should remove the lintian warning about missing man pages.
Man pages have been created by the following command:
declare -A short_desc
short_desc['compareECL']='Comparator for Eclipse files'
short_desc['convertECL']='Converter for Eclipse files (binary <-> formatted format)'
short_desc['opmhash']='Hasher for summary keywords in Eclipse files'
short_desc['opmpack']='Validator and printer of deck in Eclipse files without comments'
short_desc['summary']='Printer for summary keys in Eclipse summary files'
for key in "${!short_desc[@]}"; do
help2man -h "-h" --version-string="2020.04" --no-discard-stderr -n "${short_desc[$key]}" $key >\
$key.1
done
Gbp-Pq: Name 0005-Added-manpages-for-all-executables.patch
Whenever OPM_ENABLE_PYTHON is on we need to set PYTHON_INCLUDE_DIRS
as it is needed to find Python.h (shouldn't we even need to link the
library?).
This could (in theory) be done by using by issuing
find_package(Python3 REQUIRED COMPONENTS Interpreter Development)
or
find_package(PythonLibs REQUIRED).
Unfortunately, both do not work (for yet unknown reasons) when we
build pypi packages in docker (even with setting the PYTHON_EXECUTABLE
or Python3_EXECUTABLE correctly).
Hence we now use python manually to determine these.
FindCWrap issues another find_package(PythonInterpret).
By setting the PYTHON_EXECUTABLE variable we make sure it
will find python3
This also fixes the CMake confusions about multiple linker paths
```
Make Warning at cmake/Modules/OpmSatellites.cmake:320 (add_executable):
Cannot generate a safe linker search path for target test_ERft because
files in some directories may conflict with libraries in implicit
directories:
link library [libpython3.7m.so] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/usr/lib/python3.7/config-3.7m-x86_64-linux-gnu
Some of these libraries may not be found correctly.
```
- Enables reading of output files generated by simulator IX
- Adding support for EclFile data type C0nn (string with length > 8 characters)
- Update of program summary, now supporting well names with more that 8 characters
- Updates of program convertECL, possible to write output files with IX "format"
- updates of python bindings (EclOutput and EclFile)
cmake does not properly interpret the SYSTEM marker in lists of
include directories. this causes issues downstream when using
dunecontrol / the in-tree cmake config files.
OpmInit.cmake is one of the first includes and most importantly before
the opm-*-prereqs.cmake files are include. The macro is needed to make
the policies set in all CMakefiles. OpmSetPolicies should be called in
the toplevel CMakeLists.txt file.
This fixes a lot of warnings experienced in downstream modules that
got triggered by the opm-*-prereqs.cmake files. At some calls the
policies were at other not.
On the other hand new warnings about soon to be deprecated policies
CMP0026 and CMP0048 appear at least for cmake version 3.13.4.
But that should be fixed in another PR.
