As I understand it, python-config --cflags is intended to yield the C
compiler flags needed to compile a program that uses Python headers and
libraries (as opposed to the C flags needed to compile python itself).

However, it seems to include irrelevant options such as -Wall and -O3,
which interfere with the build (for example, by enabling optimisation in
a debug build):

$ python-config --cflags
-I/opt/Python-2.5.1/include/python2.5
-I/opt/Python-2.5.1/include/python2.5 -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes

Georg, what do you think?

I think you're right.

However, Martin, what flags except -I can/must we keep?

Some flags for the compiler are really needed to compile the Python
headers correctly, e.g. -fno-strict-aliasing in 2.6.

So I think an explicit list of options reported would have to be
maintained, either as a blacklist (e.g. -O<n>, -Wall), or as a white list.

fyi, on the mac with gcc-4.2, distutils is erroring out because of the "-
Wno-long-double" it is getting from "python-config --cflags", as it's no 
longer accepted as an argument. Fortunately this can be worked around by 
doing "CC=gcc-4.0 python setup.py".

Is this still an issue for current trunks?

It's still an issue in Python 2.6.5 as packaged by openSUSE 11.2.

I hacked up a proof-of-concept patch which filters out the most annoying flags (warnings, -Ox and -DNDEBUG flags).

(Though IMO the only really robust solution would be not having code but just declarations in the public headers, so --includes is enough. In my personal project I ended up to just use --includes and manually make sure that I don't use any of the code in the headers, but just the declarations).

I don't see the current behaviour as problematic. If you build python as a debug build, you get the -O0 included, if you do a normal build, you get the -Ox included.  At least this is behaviour found in other '-config' programs too.  So maybe add an option to filter out flags, but which ones?

The other issue is that it's unclear what these options are used for, to build an extension module, or to build an embedded interpreter. Not a difference maybe in cflags, but for ldflags. And this should be harmonized with the pkgconfig file too.

It's less of a problem when building python extenions, where you are probably fine with using "just the same" as the installed python.

However in my case I am embedding python as a scripting language into another application. So there is very few python related code and alot of other code. The python-config script "injecting" unnecessary build flags that in fact even change things (-DNDEBUG) is very annoying as it changes all the non-python code too.

A simple thing like the --includes that just outputs the -I flags would be the best solution IMO. But to have this working you would need to have a guarantee that there is no actual code in the form of #define / inline functions in the headers which potentially breaks if you use different flags from the python library. In fact --includes is what I am using now, I just hope that I won't hit any of the preproc macros by accident...

> However in my case I am embedding python as a scripting language
> into another application.

then why not filtering out these options on your own for this use case?