Support compiling portable "abi3" extension modules even when
the build host Python interpreter configuration is not available
or the discovered Python interpreter version is not supported.
Maturin already implements this by building "abi3" extension wheels
with `PYO3_NO_PYTHON` environment veriable set for cargo when
an `abi3-py3*` feature is detected.
Closes#2292
Automatically generate `python3.dll` import libraries for Windows
compile targets in the build script.
Adds a new PyO3 crate feature `generate-abi3-import-lib` enabling
automatic import library generation.
Closes#2231
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.
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.
David Hewitt