feat: Better support for cross-compilation #1050
Conversation
LecrisUT
force-pushed
the
feat/cross-compile
branch
from
1acc621 to
3e906b4
Compare
`Python_ROOT_DIR` is used for the find hints for - `Python_EXECUTABLE`: Unnecessary because we provide `Python_EXECUTABLE` as a cache variable and that has precedence - `python-config`: should point to the target's variable. Generally this is a shell script which would be executable during cross-compilation (windows case unknown) - `Python_LIBRARY`: should point to the target's library which would be on the `crossenv` uses a fake environment so that `sys.base_*_prefix` variables point to the target's system. Presumably PEP720 would work the same. Signed-off-by: Cristian Le <[email protected]>
Signed-off-by: Cristian Le <[email protected]>
Signed-off-by: Cristian Le <[email protected]>
Signed-off-by: Cristian Le <[email protected]>
Signed-off-by: Cristian Le <[email protected]>
LecrisUT
force-pushed
the
feat/cross-compile
branch
from
3e906b4 to
c8a3035
Compare
| # 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 |
There was a problem hiding this comment.
This should be inverted,
| cmake.no-python-hints = false | |
| cmake.python-hints = true |
(Applied in the definition, of course)
| # ``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.
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 D as a shortcut for cmake.define.
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.
I don't like exposing this to the pyproject.toml.
We could add a flag to the metadata.
I'd use that for
Das a shortcut forcmake.define.
A bit confused on this. Still inside --config-settings you mean?
Edit: this might be useful for overrides, though.
We could have both and deny pyproject.toml without overrides specifically. I want a more restrictive check on the build.requires as well
| 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.
| `CMAKE_TOOLCHAIN_FILE`, or the `cmake.toolchain-file` pyproject option. You may | |
| `CMAKE_TOOLCHAIN_FILE`, or the `cmake.toolchain-file` config-settings option. You may |
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.
Mostly the cross-compilation works out-of-the-box with
crossenv+CMAKE_TOOLCHAIN_FILE. There is only one adjustment needed forPython_ROOT_DIRto point tosys.base_exec_prefix, the rest is documentation of the change and adding support forCMAKE_TOOLCHAIN_FILEwhere needed.I presume that under PEP720 the same workflow will be valid, primarily
sys.base_exec_prefixwould point to the target's implementation, otherwise the document should be clarified on what to expect. I have raised the issue for further clarification 1Footnotes
https://discuss.python.org/t/pep-720-cross-compiling-python-packages/29988/2 ↩