[Python-Dev] what environment variable should contain compiler warning suppression flags?

Brett Cannon brett at python.org
Sun Jun 27 22:50:23 CEST 2010


On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
>>> AC_PROG_CC is the macro that sets CFLAGS to -g -O2 on gcc-based
>>> systems (http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fPROG_005fCC-842).
>>> If Python's configure.in sets an otherwise-empty CFLAGS to -g before
>>> calling AC_PROG_CC, AC_PROG_CC won't change it. Or we could just
>>> preserve the users CFLAGS setting across AC_PROG_CC regardless of
>>> whether it's set, to let the user set CFLAGS on the configure line
>>> without stomping any defaults.
>>
>> I think saving and restoring CFLAGS across AC_PROG_CC was attempted in
>> http://bugs.python.org/issue8211 . It turned out that it broke OS X
>> universal builds.
>
> Thanks for the link to the issue. http://bugs.python.org/issue8366
> says Ronald Oussoren fixed the universal builds without reverting the
> CFLAGS propagation.
>
>> I'm not sure I understand the importance of allowing AC_PROG_CC to set
>> CFLAGS (if CFLAGS is undefined at the point of the AC_PROG_CC);  can
>> someone give an example of why this is necessary?
>
> Marc-Andre's argument seems to be "it's possible that AC_PROG_CC adds
> other flags as well (it currently doesn't, but that may well change in
> future versions of autoconf)." That seems a little weak to constrain
> fixing actual problems today. If it ever adds more arguments, we'll
> need to inspect them anyway to see if they're more like -g or -O2
> (wanted or harmful).
>

I went ahead and reverted the change, but it does seem like the build
environment could use a cleanup.


More information about the Python-Dev mailing list