Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to run more in the SDist step? #837

Open
henryiii opened this issue Jul 30, 2024 · 3 comments
Open

Option to run more in the SDist step? #837

henryiii opened this issue Jul 30, 2024 · 3 comments

Comments

@henryiii
Copy link
Collaborator

See #766, it would be nice if we could have header only packages just build for the SDist step. Might require an option to run cmake install in the SDist step.

@LecrisUT
Copy link
Collaborator

Hmm, wouldn't cpack be more appropriate for such sdist step? Granted I never use cpack myself and that one is a weird one for users to get right.

But then, what scenario do you have in mind for this one? For header-only I think it would still be good to make a no-arch wheel, but it would depend heavily on #831 idea.

My view on this is that the headers can be generated or shipped with specific macros in the Config.cmake file, so it would fit the wheel usage, as opposed to the sdist where you are able to provide the CMake cache variables to use. It is of course weird that the header files are in the wheel, but wouldn't it need to be in that form in order to support non-header-only packages?

@henryiii
Copy link
Collaborator Author

I'm thinking of pybind11 and nanobind, specifically, which ship a *Config.cmake file. They place it in the correct location so cmake.prefix isn't necessary, scikit-build-core will find it without an entry point due to site-packages. cmake.prefix is only needed if the find name doesn't match the package name, and the new cmake.root or whatever will only be needed if the config files have a lib vs. lib64 in the structure.

It might be nice if those could produce an SDist that would be able to make a wheel without needing CMake. But both currently require CMake for the wheel, and both produce pure wheels so most users won't care about the SDist, so it's pretty minor.

@LecrisUT
Copy link
Collaborator

Ah, I guess you are making site_package folders part of the CMAKE_PREFIX_PATH and relying on the search using:

<prefix>/<name>*/(lib/<arch>|lib*|share)/cmake/<name>*/

Well, it seems like lib vs lib64 is irrelevant there based on the rule there. Are both Python_SITELIB and Python_SITEARCH searched in those cases?

About the sdist vs wheel, I was considering how would the user be using it. Let's say they have

[build-system]
requires = [scikit-build-core, pybind11]

Wouldn't pybind11 be built or downloaded from wheel regardless such that the *Config.cmake file are never consumed from the sdist?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants