-
Notifications
You must be signed in to change notification settings - Fork 63
feat: Better support for cross-compilation #1050
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
base: main
Are you sure you want to change the base?
Changes from all commits
020fdee
d6103c7
3a52a18
da7cf11
c8a3035
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -181,6 +181,14 @@ cmake.source-dir = "." | |
# DEPRECATED in 0.10; use build.targets instead. | ||
cmake.targets = "" | ||
|
||
# The CMAKE_TOOLCHAIN_FILE used for cross-compilation. | ||
cmake.toolchain-file = "" | ||
|
||
# Do not pass the current environment's python hints such as | ||
# ``Python_EXECUTABLE``. Primarily used for cross-compilation where the | ||
# CMAKE_TOOLCHAIN_FILE should handle it instead. | ||
cmake.no-python-hints = false | ||
|
||
# The versions of Ninja to allow. If Ninja is not present on the system or does | ||
# not pass this specifier, it will be downloaded via PyPI if possible. An empty | ||
# string will disable this check. | ||
|
@@ -257,6 +265,12 @@ wheel.exclude = [] | |
# The build tag to use for the wheel. If empty, no build tag is used. | ||
wheel.build-tag = "" | ||
|
||
# Manually specify the wheel tags to use, ignoring other inputs such as | ||
# ``wheel.py-api``. Each tag must be of the format | ||
# {interpreter}-{abi}-{platform}. If not specified, these tags are automatically | ||
# calculated. | ||
wheel.tags = [] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like exposing this to the pyproject.toml. Maybe we should go ahead and add a way to specify an argument is only supported via the command line. I'd use that for Edit: this might be useful for overrides, though. Maybe we should just mention that it should not be hard coded except in overrides or something like that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We could add a flag to the metadata.
A bit confused on this. Still inside
We could have both and deny pyproject.toml without overrides specifically. I want a more restrictive check on the |
||
|
||
# If CMake is less than this value, backport a copy of FindPython. Set to 0 | ||
# disable this, or the empty string. | ||
backport.find-python = "3.26.1" | ||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -1,5 +1,9 @@ | ||||||
# Cross-compiling | ||||||
|
||||||
Generally scikit-build-core will try to account for environment variables that | ||||||
specify to CMake directly how to cross-compile. Alternatively, you can define | ||||||
manually how to cross-compile as detailed in [manual cross compilation] section. | ||||||
|
||||||
## macOS | ||||||
|
||||||
Unlike the other platforms, macOS has the ability to target older operating | ||||||
|
@@ -50,10 +54,7 @@ correct suffix. These values are set by cibuildwheel when cross-compiling. | |||||
|
||||||
## Linux | ||||||
|
||||||
It should be possible to cross-compile to Linux, but due to the challenges of | ||||||
getting the manylinux RHEL devtoolkit compilers, this is currently a TODO. See | ||||||
`py-build-cmake <https://tttapa.github.io/py-build-cmake/Cross-compilation.html>`\_ | ||||||
for an alternative package's usage of toolchain files. | ||||||
See [manual cross compilation] section for the general approach. | ||||||
|
||||||
### Intel to Emscripten (Pyodide) | ||||||
|
||||||
|
@@ -64,3 +65,71 @@ by setting `_PYTHON_SYSCONFIGDATA_NAME`. This causes values like `SOABI` and | |||||
This is unfortunately incorrectly stripped from the cmake wrapper pyodide uses, | ||||||
so FindPython will report the wrong values, but pyodide-build will rename the | ||||||
.so's afterwards. | ||||||
|
||||||
## Manual cross compilation | ||||||
|
||||||
The manual cross compilation assumes you have [toolchain file] prepared defining | ||||||
the cross-compilers and where to search for the target development files, | ||||||
including the python library. A simple setup of this is to use the clang | ||||||
compiler and point `CMAKE_SYSROOT` to a mounted copy of the target system's root | ||||||
|
||||||
```cmake | ||||||
set(CMAKE_SYSTEM_NAME Linux) | ||||||
set(CMAKE_SYSTEM_PROCESSOR aarch64) | ||||||
set(triple aarch64-linux-gnu) | ||||||
set(CMAKE_C_COMPILER clang) | ||||||
set(CMAKE_CXX_COMPILER clang++) | ||||||
set(CMAKE_C_COMPILER_TARGET ${triple}) | ||||||
set(CMAKE_CXX_COMPILER_TARGET ${triple}) | ||||||
set(CMAKE_SYSROOT "/path/to/aarch64/mount/") | ||||||
``` | ||||||
|
||||||
For more complex environments such as embedded devices, Android or iOS see | ||||||
CMake's guide on how to write the [toolchain file]. | ||||||
|
||||||
You can pass the toolchain file using the environment variable | ||||||
`CMAKE_TOOLCHAIN_FILE`, or the `cmake.toolchain-file` pyproject option. You may | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
I'm not sure this is good to hard code? Though for this one (and the other), we could possibly allow it, but we probably shouldn't suggest it. It might be useful in overrides, though. Actually, maybe tags would be too. |
||||||
also need to use `wheel.tags` to manually specify the wheel tags to use for the | ||||||
file and `cmake.no-python-hints` if the target python should be detected using | ||||||
the toolchain file instead. | ||||||
|
||||||
:::{note} | ||||||
|
||||||
Because most of the logic in [`FindPython`] is gated by the | ||||||
`CMAKE_CROSSCOMPILING`, you generally should _not_ include the `Interpreter` | ||||||
component in the `find_package` command or use the `Python_ARTIFACTS_PREFIX` | ||||||
feature to distinguish the system and target components. | ||||||
|
||||||
::: | ||||||
|
||||||
:::{versionadded} 0.11 | ||||||
|
||||||
::: | ||||||
|
||||||
### Crossenv | ||||||
|
||||||
[Crossenv] cross compilation is supported in scikit-build-core. This tool | ||||||
creates a fake virtual environment where configuration hints such as | ||||||
`EXT_SUFFIX` are overwritten with the target's values. This should work without | ||||||
specifying `wheel.tags` overwrites manually. | ||||||
|
||||||
:::{note} | ||||||
|
||||||
Because the target Python executable is being faked, the usage of | ||||||
`CMAKE_CROSSCOMPILING_EMULATOR` for the `Interpreter` would not be correct in | ||||||
this case. | ||||||
|
||||||
::: | ||||||
|
||||||
:::{versionadded} 0.11 | ||||||
|
||||||
::: | ||||||
|
||||||
[manual cross compilation]: #manual-cross-compilation | ||||||
[toolchain file]: | ||||||
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling | ||||||
[crossenv]: https://crossenv.readthedocs.io/en/latest/ | ||||||
[`FindPython`]: https://cmake.org/cmake/help/git-master/module/FindPython.html |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be inverted,
(Applied in the definition, of course)