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, Дилян Палаузов <dilyan.palauzov@xxxxxxxxx> 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
