[python] Restructure module metadata file logic and use to solve 'mpi4py' issue
Fixes #271 (closed) Alternative to !1044 (closed)
This patch changes the generation of the metadata files used to store cmake flags which are needed to generate a compatible dune-py
. With this change it is fairly easy to test if HAVE_MPI
is true if so to then abort if mpi4py
could not be imported.
Changes
- store the metadata in
dune/data/modulename.cmake
- setup the metadata structure in
packagemetadata.py
and also extract the cmake flags there. - add a test for
HAVE_MPI
indune/common/__init__.py
Consequence:
- the
CMAKE_METADATA_FILE
parameter todune_python_install_package
is not used anymore. - to obtain the metadata does not require to import all subpackages anymore. This avoids educes start up time and avoids issues with circular imports.
MPI4PY
I combined this approach now with the ideas from !1044 (closed). So
-
source build: if
MPI_FOUND
is truempi4py
will be added to the requirements in the install python package function so thatmpi4py
will be added to the (internal) venv. -
package build: using the
metadata
file we can check ifHAVE_MPI
was set during the configuration ofdune-common
. Inpython/dune/common/__init__.py
we check ifHAVE_MPI
was true andmpi4py
cannot be found. In that case the script is terminated with a message informing the user to runpip install mpi4py
.
Edited by Timo Koch