luxolus
/
pyo3
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
pyo3/pyo3-build-config/Cargo.toml

41 lines
1.1 KiB
TOML
Raw Normal View History

pyo3-build-config: new crate to re-use build.rs across crates
2021-05-19 20:50:25 +00:00
[package]
name = "pyo3-build-config"
update main to reflect 0.16.5 release
2022-05-15 19:31:00 +00:00
version = "0.16.5"
pyo3-build-config: new crate to re-use build.rs across crates
2021-05-19 20:50:25 +00:00
description = "Build configuration for the PyO3 ecosystem"
authors = ["PyO3 Project and Contributors <https://github.com/PyO3>"]
keywords = ["pyo3", "python", "cpython", "ffi"]
homepage = "https://github.com/pyo3/pyo3"
repository = "https://github.com/pyo3/pyo3"
categories = ["api-bindings", "development-tools::ffi"]
license = "Apache-2.0"
edition = "2018"
[dependencies]
pyo3-build-config: fix cross compilation
2021-06-01 17:31:34 +00:00
once_cell = "1"
pyo3-build-config: switch to `python3_dll_a::ImportLibraryGenerator`
2022-05-10 07:33:08 +00:00
python3-dll-a = { version = "0.2.2", optional = true }
pyo3-build-config: Replace `TargetInfo` with `target_lexicon::Triple` 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.
2022-03-25 09:12:05 +00:00
target-lexicon = "0.12"
[build-dependencies]
pyo3-build-config: switch to `python3_dll_a::ImportLibraryGenerator`
2022-05-10 07:33:08 +00:00
python3-dll-a = { version = "0.2.2", optional = true }
pyo3-build-config: Replace `TargetInfo` with `target_lexicon::Triple` 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.
2022-03-25 09:12:05 +00:00
target-lexicon = "0.12"
pyo3-build-config: new crate to re-use build.rs across crates
2021-05-19 20:50:25 +00:00
[features]
pyo3-build-config: don't enable resolve-config by default
2021-11-19 14:19:24 +00:00
default = []
pyo3-build-config: add a crate feature to control build script 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.
2021-09-02 02:40:47 +00:00
# Attempt to resolve a Python interpreter config for building in the build
# script. If this feature isn't enabled, the build script no-ops.
resolve-config = []
pyo3-build-config: new crate to re-use build.rs across crates
2021-05-19 20:50:25 +00:00
pyo3-build-config: Build "abi3" extensions without an interpreter 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
2022-04-11 11:45:16 +00:00
# This feature is enabled by pyo3 when building an extension module.
extension-module = []
# These features are enabled by pyo3 when building Stable ABI extension modules.
pyo3-build-config: new crate to re-use build.rs across crates
2021-05-19 20:50:25 +00:00
abi3 = []
abi3-py37 = ["abi3-py38"]
abi3-py38 = ["abi3-py39"]
py310: add abi3-py310 feature
2021-09-24 21:53:55 +00:00
abi3-py39 = ["abi3-py310"]
abi3-py310 = ["abi3"]
Enable the resolve-config feature of pyo3-build-config on docs.rs to make the dependent functionality visible.
2022-03-01 09:31:38 +00:00
[package.metadata.docs.rs]
features = ["resolve-config"]