The `pip install`-step starts a new CMake-based ogs build in `_skbuild`-subdirectory (inside the source code) using the `wheel`-preset. When the CMake build is done it installs the wheel into the activated virtual environment and you can interact with it, e.g.:
The `pip install`-step starts a new CMake-based ogs build in `_skbuild`-subdirectory (inside the source code) using the `wheel`-preset. When the CMake build is done it installs the wheel into the activated virtual environment and you can interact with it.
The contents of `_skbuild/[platform-specific]/cmake-install` will make up the wheel.
### Testing
```bash
# Run python tests
...
...
@@ -52,9 +58,19 @@ python3
>>> sim.initialize(["", "--help"])
```
If you make modifications you need to run `pip install .[test]` again (or for temporary modifications you can directly edit inside the virtual environment, e.g. in `.venv/lib/python3.10/site-packages/ogs`).
If you make modifications on the C++ side you need to run `pip install .[test]` again. Modifications on the Python tests are immediately available to `pytest`.
The contents of `_skbuild/[platform-specific]/cmake-install` will make up the wheel.
Python modules added in CMake via `pybind11_add_module()` should only contain the binding code and other (helper code) which is used by that module only! If you need helper code which is used by several modules (e.g. `OGSMesh`-class used in `mesh`- and `simulator`-module) it needs to be defined in a regular library and linked to the modules.
If you don't do this you will get unresolved externals between the modules and when you try to link them together you will get runtime errors or it doesn't link at all (at least on Windows, because of the `.pyd` library format).