Open tjni opened 1 year ago
The current develop
branch of afdko has an unusual structure (given the non-standard way it adds C binaries to the path.
We have a branch currently called addfeatures
that we will likely merge into develop
sometime in the upcoming year. It almost a complete re-write and port of most of our C code into C++, and has a different organization and calling conventions. Anyway, since I ran into some build problems there I decided to port that branch to a pyproject.toml, scikit-build-core-based build. It works well!
My sense is that it would be overly disruptive to back-port those changes to develop
early, as it will be easier for down-stream consumers to absorb all the upcoming changes in one go with some advance warning rather than piecemeal. So this fix will get out into the world when we do that switch.
Hi team,
What is the temperature for migrating from scikit-build to scikit-build-core? The README of scikit-build says:
My desire from this stems from improving the packaging of this package in nixpkgs, where our need is to use system provided CMake and Ninja instead of those packages on PyPI. In scikit-build, one must specify a build-time dependency on those PyPI packages in pyproject.toml, which this project has done. However, scikit-build-core provides its own PEP 517 build backend, which therefore can detect if system CMake and Ninja are available and only fall back to the PyPI packages if they are missing.
I would be willing to work on this and submit a PR if folks agree.