avoid linking to Python #126
Conversation
|
I removed the mold code here after realizing a) the mold linker flags were actually never set, because the if conditions never triggered, b) the linker flag |
|
This should be merged into main and then into #82 to remove the need for |
|
This looks really elegant, thanks. I'm wondering how did you find this solution? |
You can follow my thoughts in the comments to #82 , but my general advice is: if you encounter a problem, study the code of scipy or numpy or pybind11, which deal with similar issues as we do and check what they are doing. These three software packages have expertly written build systems, commits are reviewed by experts with a lot of knowledge, so the solutions which end up in those packages tend to be very good. Code documentation is also often very good. In this particular case, I checked what the macro pybind11_add_module is calling to build the Python module. |
I checked scipy and numpy but they all use meson for a while 😛 |
The meson handling calls out to the meson "python" support module's There's platform-specific handling here, it's not so simple as "don't link to libpython", but that's mostly a difference between Windows (do link) and everywhere else (don't link, starting with python 3.8). |
|
We use the cmake command Python_add_library now, which is supposed to handle this in a platform independent way. Since you say it is complicated, I assume they (cmake) added this to abstract all these details away for us. |
The main goal of this PR is to fix the problems which appear on CI when
binary wheels are built using `cibuildwheel`. The main artifact is
`Release` workflow in `release.yml` file which describes the process of
building wheels and uploading them on PyPI.
The following problems were solve (in the order of their solution):
* Building wheels for Windows. It is still not solved how to build
`Pythia8` and `urqmd34` (see discussions below). So currently these
models are excluded from the build. The main trick to solve the problem
was adding the following lines in `F2Py.cmake` file:
```
if (WIN32)
target_link_libraries(${target_name} PUBLIC "-static")
endif()
```
Also there was a problem with setting correct generator in CMake and
finding `gfortran`.
* The main problem with Linux was that in Pythia8 there are 2 files:
_pythia8 and libpythia8. _pythia8 depends on libpythia8. However, during
build time `_pythia8` obtained rpath, which doesn't allow to find
libpythia8, if both files in the same directory. It was fixed by adding
`LINK_FLAGS "-Wl,-rpath...` for `_pythia8` target in CMakeLists.txt.
* With MacOS there were 2 main problems: set correct version of
`gfortran` and `c++` and linking with Python library.
- The solution of the problem with compilers was copied from
`https://github.com./numpy/numpy/tree/main/tools/wheels`.
`gfortran_utils.sh` script was copied from numpy to install the correct
version of gfortran.
- The problem with Python library was finally solved in PR #126
* The last problem solved which is worth to mention is the finding a
wrong python version via find_package(Python). The key issue was that
`cibuildwheel` uses venv but do not activate it. Because of that
find_package(Python) could not find python used in virtual environment.
It is solved by setting environment variable VIRTUAL_ENV in setup.py
---------
Co-authored-by: Hans Dembinski <[email protected]>
Co-authored-by: Hans Dembinski <[email protected]>
Co-authored-by: afedynitch <[email protected]>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com.>
Co-authored-by: Anatoli Fedynitch <[email protected]>
Co-authored-by: Henry Schreiner <[email protected]>
This seems to avoid the linking to Python, which is causing issues in #82