Chris Lambacher <report@bugs.python.org> wrote:
> I was cross-compiling to a target architecture that does not support
> the -march option so I would not be able to provide a different one
> as override. 

Just out of curiosity: You are cross-compiling a C-extension? How can
you be sure that all values in pyconfig.h are correct?

> The debian-sysconfig-flags looks the most correct because it allows
> override at any point by emulating the CFLAGS = $(BASECFLAGS) $(OPT)
> $(EXTRA_CFLAGS) logic.
> 
> It still looks like it needs an override for EXTRA_CFLAGS and the
> logic for LD_SHARED looks wrong. In the Makefile LDSHARED is just:
> LDSHARED=   $(CC) -shared -Wl,-O1 -Wl,-Bsymbolic-functions

I think Antoine is correct: EXTRA_CFLAGS show up as an empty string in
sysconfig (even if passed to configure and make), so there is no need
to override them.

As an aside, why do EXTRA_CFLAGS still exist in py3k when CFLAGS
can already be passed to configure and make?

I agree that the ldshared logic looks wrong. It is possible to specify
LDFLAGS via the environment, so why append CFLAGS. Changing this could
break existing build scripts though.

However, I don't see how the Debian patch could break anything, unless
someone relies on the fact that BASECFLAGS are suppressed in case CFLAGS
are given. I think the odds of this are virtually zero.

Any interest in a cleaned up version of the Debian patch (remove
double opt, line length, add documentation for overriding BASECFLAGS
and OPT)?

I'm asking, since I'm unsure about the degree of frozenness of distutils.