AC_PROG_CC’s recommendation for “: ${CFLAGS=""}”

[Дилян Палаузов]

Hello,

the Autoconf manual states for “Macro: AC_PROG_CC ([compiler-search-list])”:

“If using the GNU C compiler, set shell variable GCC to ‘yes’. If output 
variable CFLAGS was not already set, set it to
-g -O2 for the GNU C compiler (-O2 on systems where GCC does not accept -g), or 
-g for other compilers. If your package
does not like this default, then it is acceptable to insert the line “: 
${CFLAGS=""}” after AC_INIT and before
AC_PROG_CC to select an empty default instead.”

The common pattern is, that 
• when CONFIG_SITE rules do not apply, calling “./configure” implies passing -g 
-O2 to the compiler
• when CONFIG_SITE rules do not apply, calling “CFLAGS=-flto” implies passing 
-flto but no -g -O2 to the compiler
• when CONFIG_SITE rules do apply, calling “./configure” implies CFLAGS 
specified in config.site

With “: ${CFLAGS=""}” the third bullet/expectation still applies, but not the 
first two.

So when one wants debug information in all self-compiled autoconf-based 
packages, the user has to put CFLAGS=-g -O2 in
CONFIG_SITE.  Then it does not matter, if the package maintainer likes the 
default, the package is compiled with the
“default -g -O2”.

But if the user just calls ./configure without CONFIG_SITE, then the package 
maintainer is per documentation allowed to
tweak the default CFLAGS.

What is the rationale for this?

Usually I have CFLAGS=-O3 -flto in CONFIG_SITE and when I want to have debug 
information, I remove the overwriting from
CONFIG_SITE.  Reading the documentation this does not seem to be the right way 
to have debug information in a package, I
am supposed to add -g in CFLAGS in CONFIG_SITE.

Quite cumbersome… Posgresql goes beyond this by having “unset CFLAGS” in 
configure.in.  This is not much different than
: ${CFLAGS=""}, except it completely ignores CONFIG_SITE.  When compiling 
Postgresql CONFIG_SITE-users are supposed to
hack the resulting files and tweak them for LTO…

The documentation of Autoconf is supposed recommend common behavior of 
Autoconf-based packages, on which users can rely.

Regards
  Дилян