Adds a new cross-compile target interpreter configuration
environment variable.
This feature allows PyO3 to target PyPy on both Windows and Unix
cross compile targets.
Rename `$OUT_DIR/pyo3-cross-compile-config.txt` to
`$OUT_DIR/<triple>/pyo3-build-config.txt` to exclude the possibility
of using stale build configuration data when the build target changes.
Use the presence of the corresponding build configuration file
in the `pyo3-build-config` build script output directory
to detect whether we are cross compiling or not.
This patch enables cross compilation without using
any of `PYO3_CROSS_*` env variables in many cases.
Try to generalize `windows_hardcoded_cross_compile()`
to all supported target platforms (when possible).
Rename it to `default_cross_compile()` and add some unit tests.
Rewrite `load_cross_compile_config()` to fall back to
the default interpreter configuration when no other config
information sources are available.
Change the `CrossCompileConfig` structure definition and make
the public `lib_dir` field optional to support more flexible
cross-compilation configuration in the future.
FIXME: This change breaks the public `pyo3-build-config` crate API.
Update the sysconfigdata extraction functions to fall through
when `lib_dir` field is not set.
WIP: Add `unwrap()` stubs to the main cross compile switch.
Add a new public crate function `cross_compile_from_to()` using
`target_lexicon::Triple` arguments instead of plain strings
used in `cross_compile()`.
Deprecate `pyo3_build_config::cross_compile()` since v0.17.
Attempt to extract common code patterns into methods and standalone
helper functions. Add docstrings to the new private items.
Make some of the new helper functions public within the PyO3 crate
and reuse them in the build scripts.
Add PYO3_CROSS_PYTHON_VERSION parsing unit test.
Add a ChangeLog entry mentioning the new `pyo3-build-config` API.
* Initial refactor - expose cross-compiling functions and add necessary fields to InterpreterConfig
* Refactor cross_compiling to take arch/vendor/os separately.
* Address review comments.
* Update changelog with note about pyo3-build-config APIs.
* Fix panic when parsing ABI tag on Windows.
* Update parse_sysconfigdata test to best-guess values for linux.
* Revert added fields in InterpreterConfig.
* Refactor parse_sysconfigdata to return Sysconfigdata (HashMap). Add InterpreterConfig::from_sysconfigdata.
* Update BuildFlags test to use from_sysconfigdata.
* Add tests for from_sysconfigdata. Refactor Sysconfigdata API to be more open.
* Add basic tests for not cross compiling. Add some error handling.
* Address review comments.
* Update search_lib_dir to recurse into lib and pypy dirs.
* Look even harder for sysconfigdata.
* Add skip-build-config feature.
* Revert skip-build-config feature.
* Suppress cargo:rerun-if-env-changed without resolve-config feature.
PR #1856 was buggy in that the `pyo3-build-config` crate didn't actually
work in library mode because `include_str!()` was attempting to resolve
missing files as part of populating some `const` values.
We could change the logic of these constants to make them lazy if
we wanted to support possibly getting access to the value. But the
simple solution is to conditionalize their presence on the crate
feature.
Test coverage for building and testing the crate in insolation with the
feature disabled has been added.
Various code has been conditionalized to avoid compiler warnings.
Also, it appears `cargo build|test -p pyo3-build-config
--no-default-features` still passes default features. This seems wrong
to me. But it is how my system behaves. Maybe it is an sccache bug?
I coded the new tests to `cd pyo3-build-config` first to work around.
I have a use case in PyOxidizer where I want to use the
pyo3-build-config crate as a library crate so I can access the
`InterpreterConfig` struct so I can read/write config files without
reinventing the wheel.
This is doable before this commit. But it requires that the
build environment have a Python interpreter. This is undesirable
for library usage.
This commit introduces a cargo feature flag to control whether the
build script does anything. The feature flag must be present for
the build script to resolve a config. The feature flag is enabled
by default for backwards compatibility. The pyo3 and pyo3-macros-backend
crates use this feature by default, for backwards compatibility and
because it is the reasonable default.
This is probably room to conditionalize some APIs and other behavior
based on this feature flag. But we stop short of doing that for
the time being.
Sergey Kvachonok