henryiii
commented
4 weeks ago Have you activated all verbosity options? SKBUILD_BUILD_VERBOSE=1 and SKBUILD_LOGGING_LEVEL=DEBUG are the envvar versions. Comparing a working and failing build would be very interesting!
Using #include "../<stuff>" is somewhat poor form, public headers should be included via <project/...> (and including from a parent directory in the first place is poor structure). But I'm guessing since it's very specific, this likely isn't the problem. Though I'm slightly curious if we made a branch with absolute references here how the error message would change.
By the way, for free-threading on Windows, you have to define Py_GIL_DISABLED on Windows. See https://gitlab.kitware.com/cmake/cmake/-/issues/26016.
burgholzer
charliermarsh
Description
Hi 👋🏼
First things first: I am not 100% sure what I am about to describe is a cibuildwheel issue, but it was the only scenario under which I could reproduce the issue. Feel free to transfer this issue to its appropriate place or point me there.
Context
We are currently working on improving one of our libraries (https://github.com/cda-tum/mqt-qcec, built in C++, exposed to Python via pybind11, using scikit-build-core as a build backend) to get some of its build time dependencies (including C++ shared libraries) via another one of our packages (https://github.com/cda-tum/mqt-core; same setup as the other tool) kind of similar to how
pybind11is distributed as a Python package and can then be found viafind_packagein CMake.The respective PRs in question are: https://github.com/cda-tum/mqt-qcec/pull/432 and https://github.com/cda-tum/mqt-core/pull/662
For the development, we added
mqt.coreas a git dependency to themqt.qcecpackage configuration (see here):Almost everything works smoothly with this setup and nearly all the CI workflows are green, except one:
Problem
Running
cibuildwheelon Windows to build Python 3.13 free-threading wheels. A corresponding failing CI log can be found here. Interestingly, it fails to properly build themqt.coregit dependency from the build requirements. The errors from the CI log all boil down to something similar asindicating that something is messed up with the pybind11 include directories.
Note that the same job succeeds on Ubuntu (also with emulation based on QEMU), macOS (x86 and arm64), as well as Windows (despite the 3.13t job), as can be seen from all the build logs here.
The cibuildwheel configuration of the
mqt.qcecproject is here.What I tried to narrow down the problem
This is only happening on Windows and for Python 3.13t
We are using the
build[uv]build frontend and the errors are isolated to that particular choice. More precisely, they are limited to the use ofuvas the installer. Both, choosing justbuildas well as the regularpipfrontend in the cibuildwheel config makes the job succeed.Installing Python 3.13t from the official website, creating a new virtual environment with
uvusing that Python version and runninguv pip install .in a fresh clone of themqt-qcecbranch also succeeds without issuesRunning
python -m build --wheel --installer=uvin a newly createduvPython 3.13t venv also succeeds.This was tested with
uv 0.2.37, but also failed with a couple versions before that.Running cibuildwheel on the
mqt.coresub-project runs successfully, even on windows with Python 3.13t. See the corresponding CI log.Running
pipx run cibuildwheel --only cp313t-win_amd64consistently fails with the above errors.Steps to reproduce the problem
On a Windows machine with pipx installed:
The issue is probably right at the intersection of
cibuildwheel,scikit-build-core,pybind11,uvand some Python 3.13 free-threading change. However, even after longer sessions of debugging, I couldn't really make sense of it.Build log
https://github.com/cda-tum/mqt-qcec/actions/runs/10392166048/job/28783894623
CI config
https://github.com/cda-tum/mqt-workflows/blob/a9a471582a6aefc2a71ab50772707829edb2abc3/.github/workflows/reusable-python-packaging.yml#L67-L118