PyOxidizer requires advanced control over the settings used to link
libpython. We recently implemented support for configuration files
defining explicit lines to emit from build scripts to give callers
control over what lines to emit from build scripts so use cases
like PyOxidizer's are feasible without hacks in PyO3's code base.
However, the default logic in `emit_link_config()` may not be
appropriate in scenarios where link settings are provided via this
"extra lines" mechanism. The default logic may prohibit use of or
interfere with desired settings provided externally.
This commit defines a new field on the interpreter config that
suppresses the emission of the default link control logic from the
`pyo3` build script. It effectively gives advanced consumers like
PyOxidizer full control over link logic while minimally polluting
PyO3's build logic.
I thought about implementing this control as a crate feature. But
given the expected target audience size of ~1, I thought a crate
feature was too visible for a power user feature and decided to
implement it via the configuration file.
PyOxidizer needs to do some... questionable things with regards to
configuring how the Python interpreter is linked. The way I solved this
problem for the `cpython` / `python3-sys` crates was by adding a bunch
of crate features to control what `cargo:` lines were emitted by the
build scripts. This added a lot of complexity to the those crates for
a target audience of ~1.
Now that PyO3 has support for config files to control settings, this
provides a richer mechanism than crate features to influence the build
script.
This commit defines a new field on the `InterpreterConfig` struct to
hold an arbitrary list of strings/lines that should be emitted by
the build script. This field is only every populated when parsing config
files and it is only read by pyo3's build script to `println!()`
additional values.
My intended use case for this is to have PyOxidizer effectively control
the interpreter link settings via the config file (at my own peril)
while having minimal impact on the maintainability of PyO3's code base.
Given the complexity of the link hacks employed, you probably don't want
this polluting pyo3's code base.
When using rust after this commit
1a491e2304
the target family for wasm targets is now set to "wasm". Also fix the
assumption that OsStrExt lives inside std::os::unix for all non-windows
targets.
The config header parsing code was supposed to be only invoked when
cross-compiling for Windows, but in reality it fails to correctly parse
the config header files shipped with the upstream Python for Windows.
Given that there are now better options for reliable cross-compiling
for Windows such as `PYO3_CROSS_PYTHON_VERSION` or the `abi3-py3*` features,
it should be OK to remove this config for v0.14.
Update the cross-compilation instructions section of the user guide.
Fixes https://github.com/PyO3/pyo3/issues/1337
Setting `PYO3_NO_PYTHON` results in an extension module built with
a different config feature set (on Windows).
Specifically, `Py_SHARED` config option gets omitted in this code path.
Maturin always sets `PYO3_NO_PYTHON` when cross-compiling abi3 extensions,
which creates a subtle configuration mismatch between `cargo build`
and `maturin build` artifacts.
Always set `Py_SHARED` when compiling abi3 extensions for Windows.
Compiling an abi3 extension module for `x86_64-pc-windows-gnu` target
links to `python3.dll` import library when `PYO3_NO_PYTHON` is set
and to `python3.Y.dll` import library when `PYO3_NO_PYTHON` is not set.
All abi3 extensions should link to `python3.dll` on Windows,
as required by
https://www.python.org/dev/peps/pep-0384/#linkage
Update the code path for the case when `PYO3_NO_PYTHON` is not set
to yield the same Python DLL import library name.
The DLL of the mingw Python in MSYS2 is named libpython3.8.dll:
$ python3 -m sysconfig | grep LIBPYTHON
LIBPYTHON = "-lpython3.8"
Add another special case to in get_rustc_link_lib() to handle that case.
Afaik the mingw build doesn't support the limited ABI, so skipt that as well.
This makes all tests pass in an MSYS2 environment and lets us build
python-cryptography.
Gregory Szorc