[BUG] setuptools 75.7.0 and CFLAGS

[stanislavlevin]

setuptools version

75.7.0

Python version

3.12.8

OS

ALTLinux

Additional environment information

No response

Description

With pypa/distutils#299 (merged to setuptools 75.7.0) the CFLAGS behavior changed.
Docs are not updated to that change and describe the previous state.

https://setuptools.pypa.io/en/latest/userguide/ext_modules.html#compiler-and-linker-options

The compiler options appear in the command line in the following order:

• first, the options provided by the sysconfig variable CFLAGS,
• then, the options provided by the environment variables CFLAGS and CPPFLAGS,

This is the behavior used for RPM build for long time. CFLAGS was/is used to append additional distro-specific options to the CPython's ones.

After the aforementioned change CFLAGS env variable overrides sysconfigs CFLAGS and it's no longer possible to supply additional flags.

So it's a behavior change.

Expected behavior

There should be a way to pass additional flags for compilers according to documentation.

How to Reproduce

Try to build an extension with CFLAGS and without to see the difference in compiler flags.

Output

[thesamesam]

I'm not completely sure what the complaint here is. I agree the docs need to be updated (wasn't aware of them), but the new behaviour matches every other build system.

After the aforementioned change CFLAGS env variable overrides sysconfigs CFLAGS and it's no longer possible to supply additional flags.

It's completely possible to supply additional flags? Just pass CFLAGS="${CFLAGS} -fwhatever-i-want-to-add" in your RPM .spec? If CFLAGS is unset in the environment, it still uses the sysconfig CFLAGS anyway (which I'd like to possibly change, but it's separate to this discussion).

So, in your case, you have set CFLAGS, in which case you can set it further and append something to that value.

Please also note that many Python packages building C extensions don't use setuptools or distutils anyway, so you would need that infrastructure for them before this.

In summary, the only action I see as necessary here is to update the documentation, which I will handle.

Aside: please CC people relevant to a discussion / commit / bisect result in bug reports. I only found this by complete chance.

[eli-schwartz]

This appears to be a misguided report based on the confusion at python/mypy#18610 (comment)

It happened because mypy has buggy code but it wasn't being checked by default iff your cpython happened to be built with -DNDEBUG. The setuptools change made it possible to check buggy code for assertion failures, which caused mypy to assert, so I cannot possibly see the setuptools change as a bad thing.

[stanislavlevin]

I'm not completely sure what the complaint here is.

The behavior that was documented and could be relied on worked for years. But it has been changed without any reason.

There is no standard that regulates usage of CFLAGS (correct me if I'm wrong), it can be used to either override project's
options passed to compiler or append to them. From my personal subjective experience it's mostly the latter.

setuptools has been stuck to append. And now it has been changed.

[stanislavlevin]

It happened because mypy has buggy code but it wasn't being checked by default iff your cpython happened to be built with -DNDEBUG. The setuptools change made it possible to check buggy code for assertion failures, which caused mypy to assert, so I cannot possibly see the setuptools change as a bad thing.

Not a bad thing is fixing a problem without 100500 unrelated questions ;)

[thesamesam]

But it has been changed without any reason.

No, this isn't true. Please assume good faith. There are several reasons:

• consistency with CXXFLAGS, as noted in the commit message
• consistency with other build systems (both inside of the Python ecosystem and outside)
• allowing Python packages using setuptools to be built with another compiler than was used to build CPython (if you use a flag that is incompatible when building CPython itself..)
• avoiding unexpected behaviour (e.g. building CPython with -DNDEBUG, then suddenly it appears in all package builds)

There is no standard that regulates usage of CFLAGS (correct me if I'm wrong), it can be used to either override project's
options passed to compiler or append to them. From my personal subjective experience it's mostly the latter.

I have extensive experience packaging and it's considered a bug when something hardcodes/calcifies CFLAGS from the build of another package. It causes all sorts of problems. Note that we are not overriding the CFLAGS used by a specific project anyway, but rather just whatever CPython happens to use -- but you couldn't rely on that anyway, as other (even Python) build systems didn't do that.