How exactly does pyo3-build-config's #[cfg(...)] macros work?

[jymchng]

Hi, I have been coding Rust for around two years - I'd also written some procedural macros and a few crates - so I understand how macros work, etc. Thank you for building pyo3.

From this, I understand how pyo3 sets certain --cfg / --check-cfg flags to rustc.

If we look at this piece of code copied from the documentation:

#[cfg(Py_3_7)]
fn function_only_supported_on_python_3_7_and_up() {}

The following points can be made:

1. pyo3 does not control the attribute macro #[cfg(...)], it is controlled by rustc.
2. pyo3 does not control the client's codes, e.g. the function function_only_supported_on_python_3_7_and_up().
3. All pyo3 has is the flag Py_3_7, which in the client's build.rs script will be passed to rustc and set as a flag.
4. Even if pyo3 can possibly get the --cfg flag (by interrogating rustc or through environment variables) - knowing if Py_3_7 is set; pyo3 still doesn't control #[cfg(...)] so it can't control how the function function_only_supported_on_python_3_7_and_up() is expanded.

Hence, my question:

How did pyo3 accomplish this?
From knowing if a flag, e.g. Py_3_7, is set or not to conditional compilation of codes depending on whether the Python executable is of version 3.7 and above.

Thank you.

[jymchng]

@davidhewitt and others, do you guys have an opinion on this?

[davidhewitt]

The cfg flags are set according to the interpreter which pyo3-build-config finds when it's being completed. We don't need to change the way cfg is expanded.

[jymchng]

Consider the example codes from the documentation:

#[cfg(Py_3_7)]
fn function_only_supported_on_python_3_7_and_up() {}

#[cfg(not(Py_3_8))]
fn function_only_supported_before_python_3_8() {}

#[cfg(not(Py_LIMITED_API))]
fn function_incompatible_with_abi3_feature() {}

If it has detected that the Python execution is of version 3.9, then it will set the flags Py_3_8 to be false and consequently, the second function will not be compiled?

[davidhewitt]

Not quite, if Python 3.9 then we set Py_3_8 too. You should think of Py_3_8 as meaning "at least Python 3.8".

[messense]

See also

pyo3/pyo3-build-config/src/impl_.rs

Lines 162 to 172 in a5a3f3f

	pub fn build_script_outputs(&self) -> Vec<String> {
	// This should have been checked during pyo3-build-config build time.
	assert!(self.version >= MINIMUM_SUPPORTED_VERSION);
	let mut out = vec![];
	// pyo3-build-config was released when Python 3.6 was supported, so minimum flag to emit is
	// Py_3_6 (to avoid silently breaking users who depend on this cfg).
	for i in 6..=self.version.minor {
	out.push(format!("cargo:rustc-cfg=Py_3_{}", i));
	}

[jymchng]

Not quite, if Python 3.9 then we set Py_3_8 too. You should think of Py_3_8 as meaning "at least Python 3.8".

Thank you.

In this case, then all 3 functions in the codes example should compile into the binary.

If Python is 3.5, then I guess the second and third function will compile.

If 3.7, then all 3 functions should compile.

[jymchng]

See also

pyo3/pyo3-build-config/src/impl_.rs

Lines 162 to 172 in a5a3f3f

	pub fn build_script_outputs(&self) -> Vec<String> {
	// This should have been checked during pyo3-build-config build time.
	assert!(self.version >= MINIMUM_SUPPORTED_VERSION);
	let mut out = vec![];
	// pyo3-build-config was released when Python 3.6 was supported, so minimum flag to emit is
	// Py_3_6 (to avoid silently breaking users who depend on this cfg).
	for i in 6..=self.version.minor {
	out.push(format!("cargo:rustc-cfg=Py_3_{}", i));
	}

Thank you for sharing.