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

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

Hello,

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

Does this mean, that using from 
https://www.gnu.org/software/autoconf-archive/ax_check_enable_debug.html 

AX_CHECK_ENABLE_DEBUG([no])

in configure.ac contradicts the GNU Coding Standards?



On Fri, 2019-03-08 at 15:18 -0500, Nick Bowler wrote:
> 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 to 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