On Sun, Jun 27, 2010 at 13:37, Jeffrey Yasskin <jyass...@gmail.com> wrote: > On Sun, Jun 27, 2010 at 1:04 PM, Mark Dickinson <dicki...@gmail.com> wrote: >> On Sun, Jun 27, 2010 at 6:46 AM, Jeffrey Yasskin <jyass...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com