-
Notifications
You must be signed in to change notification settings - Fork 117
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
Avoid PythonLibs
and PythonInterp
due to CMP0148
#1019
base: main
Are you sure you want to change the base?
Conversation
As a note for something not in the description: there are other uses of I am not sure if these other uses of |
If we just hard switch, this will break all downstream packages that use the variables set by FindPythonLibs/FindPythonInterp. It will also require a really new CMake version (scikit-build-core backports FindPython from 3.26 so that it works on 3.15+). What I'd do if we really want to save FindPythonExtensions is have it respect FindPython and not trigger FindPythonLibs/Interp if FindPython has already run. That's how pybind11 handles this. Longer term, scikit-build-core doesn't have "FindPythonExtensions". If you use FindPython, there's very little if any need to use FindPythonExtensions. It was only needed to fill in missing parts of FindPythonLibs/FindPythonInterp. |
Yep! I totally agree ... when I started needing to make any changes to the external visibility of
I guess this is a question for you, and not one I can answer: do you?
Seems like a very reasonable change.
I can take a look at this and see if I can bring this change across to scikit-build.
Maybe I'm using it wrong then: I was using FindPythonExtensions to get |
For FindPython, you can use |
Yeah, it seems that: add_library(${module} MODULE ${module})
python_extension_module(${module}) Has the same result as: Python_add_library(${module} MODULE WITH_SOABI ${module}) However, |
add_executable(myexe ...)
target_link_libraries(myexe PRIVATE Python::Python) ? |
Just chiming in as a maintainer helping a few people cross compile.
I really wonder if a newer version of cmake would be in the spirit of SPEC0. All in all, those that are using old software likely in maintenance mode, and don't really need to update any of them, let alone something like scikit build. Depending on how far you want to go:
I think that Ultimately, cross compilation is becoming more and more important with new architectures poping up every year. I think some breaking changes might be necessary in order to help push things forward. |
This PR aims to avoid the use of
PythonLibs
andPythonInterp
due to CMP0148, which was introduced in CMake 3.27.Closes #1018.