This was missing proper quoting for the case that dune-common_CXX_FLAGS
is empty.
Error I got was:
```
-- Version 2.10.0 of dune-common from /home/mblatt/src/dune/opm-master/dune-common/opm-parallel
CMake Error at CMakeLists.txt:369 (string):
string sub-command REPLACE requires at least four arguments.
-- Configuring incomplete, errors occurred!
```
the embedding headers are not available on the manylinux2014 containers
used to build the pypi packages. since this is anyways more correct
fix it this way
It is needed as we will call pybind11_add_module which calls
python3_add_library (in recent pybind11 versions). That
function is only there if the development component is searched for
and found.
g++-12 needs quite some memory and time to compile it.
We now use several Builtin*.cpp for the imlementations for different
starting letters of eclipse keywords to use less resources for
compiling.
Otherwise boost components found by previous search will be marked as
not found if a new component is not found in the new search.
This happend for #3381 if regex was not found and made cmake believe
that unit_test_framework was not found either. Even though it was in a
previous search.
Now we make sure to CONFIG mode if boost was found before, which fixes
this problem. Also we only link dunecommon to test if they are
actually built (read unit_test_framework was marked as found).
Closes#3881
Thus we get rid of the warning:
WARNING: Testing via this command is deprecated and will be removed in
a future version. Users looking for a generic test entry point
independent of test runner are encouraged to use tox.
Convert the Python opm package from a regular package to a namespace
package such that opm-simulators can contribute to the package from a
different filesystem path. In this way, the two packages opm.simulators
and opm.io (for example) can have a different parent filesystem path.
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
Instead of checking whether this is Debian system we query the
sitepackages path from Python. If it matches dist-packages then
we use dist-packages if we install below /usr, otherwise site-packages
is used.
Compiling will fail at a very late stage and might cause surprises
for novice users. It seems much better to issue an error in CMake with
a meaningful error message. Might prevent some support issues in the
future.
If cmake is run with `-DOPM_ENABLE_EMBEDDED_PYTHON=ON -DOPM_ENABLE_PYTHON=OFF`
a cmake error was produced because the library would depend on
python/cxx/builtin_pybind11.cpp which would not be generated.
We fix this by doing the Python sanity check (deactivate embedded
python if python is disabled) before running source_hook that adds the
dependency.
Closes#2940
It is used verbatim in setup.py in the list that specifies the linker
flage. Hence it needs to comma separted instead of using a semicolon
as separator.
We also rename it to SETUP_PY_LINKAGE to indicate where it is used.
Closes#2947
Currently, an rpath to the install directory of libopmcommon.so is
generated for libopmcommon_python.so, but a similar rpath is not added to
the libopmcommon.so in the build directory. It is useful to be able to
use the build directory libraries when not compiling with
-DOPM_INSTALL_PYTHON or when developing.
This PR fixes issue #2843.
