classification
Title: -Werror=statement-after-declaration problem
Type: behavior Stage: resolved
Components: Build, Distutils Versions: Python 3.4
process
Status: closed Resolution: duplicate
Dependencies: Superseder: -Werror=declaration-after-statement is added even for extension modules through setup.py
View: 21121
Assigned To: eric.araujo Nosy List: Arfrever, benjamin.peterson, christian.heimes, eric.araujo, jkloth, ronaldoussoren, tarek, vstinner
Priority: normal Keywords:

Created on 2013-06-14 11:50 by ronaldoussoren, last changed 2014-05-04 18:08 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
issue18211-hack.txt ronaldoussoren, 2013-06-18 12:47 review
issue18211-hack-v2.txt ronaldoussoren, 2013-06-18 13:08 review
Messages (11)
msg191119 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-06-14 11:50
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.
msg191311 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-06-17 02:47
Yes, we definitely need some way for CPython compiler flags to not infect everything built with distutils.
msg191404 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-06-18 12:47
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.
msg191405 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-06-18 13:08
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.
msg191407 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-06-18 13:13
The setup.py issues are in #18255.
msg191415 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-06-18 15:04
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.
msg193158 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-07-16 10:07
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).
msg193182 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-07-16 16:14
Why not?
msg193607 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-07-23 15:53
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).
msg217872 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2014-05-04 12:40
Closing this one because Issue21121 contains a usable patch.
msg217873 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2014-05-04 12:41
Sigh. Actually closing doesn't work due to the dependency :-(
History
Date User Action Args
2014-05-04 18:08:47eric.araujosetstatus: open -> closed
dependencies: - CPython setup.py problems
stage: needs patch -> resolved
2014-05-04 12:41:04ronaldoussorensetmessages: + msg217873
2014-05-04 12:40:21ronaldoussorensetsuperseder: -Werror=declaration-after-statement is added even for extension modules through setup.py
resolution: duplicate
messages: + msg217872
2013-07-23 15:53:29ronaldoussorensetmessages: + msg193607
2013-07-16 16:14:40benjamin.petersonsetmessages: + msg193182
2013-07-16 10:07:09vstinnersetmessages: + msg193158
2013-07-16 10:04:57vstinnersetnosy: + vstinner
2013-06-18 15:04:16ronaldoussorensetmessages: + msg191415
2013-06-18 13:13:54ronaldoussorensetdependencies: + CPython setup.py problems
messages: + msg191407
2013-06-18 13:08:03ronaldoussorensetfiles: + issue18211-hack-v2.txt

messages: + msg191405
2013-06-18 12:47:39ronaldoussorensetfiles: + issue18211-hack.txt

messages: + msg191404
2013-06-17 02:52:03Arfreversetnosy: + Arfrever
2013-06-17 02:47:23benjamin.petersonsetmessages: + msg191311
2013-06-14 14:06:16jklothsetnosy: + jkloth
2013-06-14 12:30:23christian.heimessetnosy: + christian.heimes
2013-06-14 11:50:35ronaldoussorencreate