homepage

Changeset a3559c8c614b added -Werror=statement-after-declaration to the CFLAGS for compiler that support it. 
This new flags is fine for CPython itself (which is explicitly writting in C89 style to support older compilers and Microsoft Visual Studio), but the new flags also gets used when building 3th-party extensions using distutils and might cause problems there when that code uses C99.
I don't have a good solution for this yet, the flag is useful to have when building CPython to avoid regressions in C89 support but shouldn't be used when building 3th-party extensions.

Yes, we definitely need some way for CPython compiler flags to not infect everything built with distutils.

Is "-Werror=statement-after-declaration" the right solution anyway? This errors out on just one of the incompatibilities between C89 and C99, although it is one that is easy to get wrong accidentally.
Gcc (and clang) also support '-std=c89' that forces the compiler to support only that standard. Not that switching to that flag would get us closer to closing this issue :-)
BTW. To make things more fun: both sysconfig and distutils.sysconfig contain code to parse the Makefile, and those two sets of code are not equivalent (distutils.sysconfig lets you override values using the environment, sysconfig does not). 
The attached crude hack fixes this particular issue, but I'm far from convinced that is is the right solution for two reasons: first of all it is a hack, second of all it drops the -Werror flag when building CPython's extensions.
A better solution would be the introduction of a new variable in the Makefile that contains those CFLAGS that should only be used during the build of Python itself, all those flags can then be ignored by the Makefile parsers in distutils.sysconfig and sysconfig. The disadvantage is that is introduces even more complexity in the Makefile.

I had a patch that only changed distutils.sysconfig.get_config_var('CFLAGS') when not building python, but then noticed that this doesn't work: the setup.py file for stdlib extensions fetches information from the toplevel sysconfig file, not distutils.sysconfig and uses that to override some information (look for "make CC=altcc").
There are two problems there, for which I'll file separate issues:
1) setup.py shouldn't use sysconfig but distutils.sysconfig
2) the block of code that I mentioned earlier is not necessary at all, the comment is plain wrong (tested by removing the compiler update and running 'make CC=no-such-file')
V2 of the hack triggers the change of BASECFLAGS only when not building the stdlib, but that doesn't work right now because of the issues mentioned earlier.

The setup.py issues are in #18255.

I just noticed the patch is not good enough: "python-config --cflags" still prints the -Werror flag because it is now a shell script and doesn't use sysconfig data at all.

By the way, I don't think that Python should pass the optimization level (-O0 or -O3) to extensions, except for builtin extensions (of the stdlib).

Why not?

I also don't understand why the optimization level shouldn't be used when building 3th-party extensions. 
Removing the -O flag for build_ext would be a regression compared to the current behavior because 3th-party extensions would suddenly be compiled with less optimization than before and extension authors would have to arrange for those flags themselves. That's fine on platforms using a compiler with a command-line interface that's simular to GCC, but the are compilers that don't (such as a number of vendor compilers for the various commercial unix systems).

Closing this one because Issue21121 contains a usable patch.

Sigh. Actually closing doesn't work due to the dependency :-(