celtera
Python pyproject package
Hi,
I've taken some time to adapt the python binding in order to be able to build wheels.
This includes:
- Writing the
pyproject.toml - Modifying the build script to manually link boost and adding the install statement to include the pyd into the wheel
Additionally I added a FetchContent for boost 1.89 int the deps cmake file so that the build process "just works". I have not tested if this causes an issue somewhere else!
I've successfully used pip wheel . to build the project with python 3.13 on windows.
Hi,
As requested I updated the license and authors.
I also added an explicit check for readerwriterqueue in the cmake of the binding because it sometimes refused to build the first time for some reason and I don't know enough to figure out why.
Is there a reason this requires scikit ?
Maybe not but it's the easiest/fastest way I found to integrate cmake+nanobind in the packaging process.
Do you know if this builds with uv too?
It does.
There is an edge case where if it needs to download boost, it might fail due to the file path/name being too long. This can be fixed by tweaking the cache settings of uv.
It works for me with python build process, but it appears that the CI in place fails because I added the link to Boost::variant2 and Boost::container. How did it work before if boost wasn't linked?
It's clearly finding it (Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake) for the library, but not for the python binding.
I could add a sanity check the same way I did for readwriterqueue?
How did it work before if boost wasn't linked?
the huge majority of boost libraries are header-only and don't need linking, you can just link to the main boost target. If you specify components I think you have to add which components you are looking for in the boost find_package call, e.g.
find_package(Boost 1.89 COMPONENTS Cobalt etc.)