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

[Nick Bowler]

Hello,

On 2019-03-08, Дилян Палаузов <address@hidden> wrote:
> 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.

Configuring with CFLAGS=-flto should work fine.  The suggested code
doesn't do anything if CFLAGS is already set in the environment.

> 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?

Because if the defaults are not appropriate for whatever reason then it
is useful to be able to change them.

> 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.

I'm not sure what exactly the problem is here?  Generally people using
the config.site mechanism would write their scripts with a similar
pattern so that the config.site defaults can be easily changed.

> Quite cumbersome… Posgresql goes beyond this by having “unset CFLAGS”
> in configure.in.  This is not much different than : ${CFLAGS=""},

It is very different, "unset CFLAGS" will override the user-set CFLAGS,
but : ${CFLAGS=""} will not override the user set CFLAGS.

Obviously "unset CFLAGS" goes against the GNU Coding Standards, but ...

> except it completely ignores CONFIG_SITE.  When compiling Postgresql
> CONFIG_SITE-users are supposed to hack the resulting files and tweak them
> for LTO…

... if postgresql's build system has problems then it is something you
should take up with the developers of that build system.

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

So you'd like this paragraph to be deleted from the manual?  How will
that benefit anyone?

The documentation of Autoconf is, among other things, supposed to tell
Autoconf users how to use Autoconf.  This description of how one can
tweak default the CFLAGS set by Autoconf-supplied macros is squarely
in that category.

Generally Autoconf tries to assist with making build systems that follow
the GNU Coding Standards, but that is not the only way to make a build
system and also not the only reason one might wish to use Autoconf.

Regardless, the only thing the GNU Coding Standards has to say about
default CFLAGS is that package authors _should_ include -g.

Cheers,
  Nick