Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/28/2009 3:20 PM: >>> -# AC_DEFUN_ONCE(NAME, VALUE) >>> +# AC_DEFUN_ONCE([NAME], VALUE) >>> # -- >> Lengthen the separator line by two dashes, then commit. > > I disagree. Inside autoconf macro do

Re: expand-before-require bug

Eric Blake wrote: > > How about this work-around? > > > > > > -# AC_DEFUN_ONCE(NAME, VALUE) > > +# AC_DEFUN_ONCE([NAME], VALUE) > > # -- > > Lengthen the separator line by two dashes, then commit. I disagree. Inside autoconf macro documentation, brackets denote optional a

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/28/2009 6:05 AM: > At least autoconf-2.59 warns: > > gnulib/m4/00gnulib.m4:11: warning: underquoted definition of NAME Over-eager sed script, if it is detecting and warning about the comments. > > How about this wor

Re: expand-before-require bug

Eric Blake wrote: ... >>From fcf62c3dfcc0a9ca32860327494e9971623f062c Mon Sep 17 00:00:00 2001 > From: Eric Blake > Date: Mon, 26 Jan 2009 09:08:48 -0700 > Subject: [PATCH] Backport improved autoconf semantics of AC_DEFUN_ONCE. > > * m4/00gnulib.m4: New file. Hi Eric, First, thanks for all your

Re: expand-before-require bug

Eric Blake wrote: > Silence warning reintroduced by recent extensions patch. > * m4/extensions.m4 (AC_USE_SYSTEM_EXTENSIONS) > (gl_USE_SYSTEM_EXTENSIONS): Use AC_DEFUN_ONCE to silence newer > autoconf. > > Backport improved autoconf semantics of AC_DEFUN_ONCE. >

Re: expand-before-require bug

* Ralf Wildenhues wrote on Mon, Jan 26, 2009 at 08:30:41PM CET: [...] sorry for the noise, I did not read the whole thread before replying.

Re: expand-before-require bug

* Eric Blake wrote on Mon, Jan 26, 2009 at 12:36:25AM CET: > > Backporting within gnulib-common.m4 itself won't work - we have to > redefine AC_DEFUN_ONCE before any other gnulib .m4 file that uses it to > define another macro. Fortunately, Automake collects all m4/*.m4 files in > alphabetical or

Re: expand-before-require bug

> Backporting within gnulib-common.m4 itself won't work - we have to > redefine AC_DEFUN_ONCE before any other gnulib .m4 file that uses it to > define another macro. Since it is just two lines of code, we can just use the same AC_DEFUN([...], [AC_REQUIRE([$0_BODY])]) AC_DEFUN([$0_BODY], [...])

Re: expand-before-require bug

Bruno Haible clisp.org> writes: > This patch introduces > "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS" > warnings in gettext, with autoconf 2.63. (gettext uses AC_GNU_SOURCE > in a couple of places, and even though the macro is marked obsolete, > it's not invalid to use it.) A

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/23/2009 5:26 PM: > Eric Blake wrote: >> With the proposal for autoconf 2.64, it can be >> either invoked or required, in any order, without warning; it guarantees >> that the expansion only occurs once; and it will never

Re: expand-before-require bug

Eric Blake wrote: > * gnulib-tool (func_dest_tmpfilename, func_create_testdir): Using > obsolete AC_GNU_SOURCE causes out-of-order expansion; avoid it, > and rely solely on gl_USE_SYSTEM_EXTENSIONS. This patch introduces "AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS" warnings in

Re: expand-before-require bug

Eric Blake wrote: > With the proposal for autoconf 2.64, it can be > either invoked or required, in any order, without warning; it guarantees > that the expansion only occurs once; and it will never suffer from > out-of-order expansion (thanks to the embedded require under the hood). Sounds perfec

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/23/2009 4:26 PM: > I find this m4_defun_once interesting too: it incorporates the workaround > that we previously used in gnulib. > > But before you jump to the conclusion that AC_DEFUN_IDEMPOTENT is not > needed any mor

Re: expand-before-require bug

Eric Blake wrote: > > m4_define([m4_defun_once], [dnl > > m4_defun([_$0_$1], [$2])dnl > > m4_defun([$1], [m4_require([_$0_$1])]) > > I like this idea. ... I don't think we need > AC_DEFUN_IDEMPOTENT; rather, we just make AC_DEFUN_ONCE the single macro > that is the user's way to declare tha

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 1/23/2009 5:25 AM: >>> It's too late for doing that: AC_DEFUN_ONCE was introduced on 2004-10-11. >> I know. >> >>> Besides that, AC_DEFUN_ONCE and AC_DEFUN_IDEMPOTENT have really opposite >>> semantics. You cannot confuse

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 1/23/2009 1:46 AM: > I don't like this too. Does it work to simply change gl_INIT to > m4_define?!? No, because we currently forbid direct calls to AC_REQUIRE at the top level (although I would like to get rid of that re

Re: expand-before-require bug

>> It's too late for doing that: AC_DEFUN_ONCE was introduced on 2004-10-11. > > I know. > >> Besides that, AC_DEFUN_ONCE and AC_DEFUN_IDEMPOTENT have really opposite >> semantics. You cannot confuse people more than by using the same name for >> two entities with opposite semantics. > > It loo

Re: expand-before-require bug

Bruno Haible wrote: > Paolo Bonzini wrote: >>> - macros defined with AC_DEFUN_IDEMPOTENT are *known* to be expandable >>> any number of times, hence they may be both invoked and required, >>> >>> - macros defined with AC_DEFUN_ONCE are *known* to be expandable only >>> once, hence the r

Re: expand-before-require bug

Paolo Bonzini wrote: > > - macros defined with AC_DEFUN_IDEMPOTENT are *known* to be expandable > > any number of times, hence they may be both invoked and required, > > > > - macros defined with AC_DEFUN_ONCE are *known* to be expandable only > > once, hence the recommendation for the

Re: expand-before-require bug

Hi Eric, > > But no, I don't want to > > think about AC_REQUIRE's bug every time I want to invoke an autoconf macro! > > My argument is that if Autoconf can enforce rules, such as refusing to > compile if you try to expand instead of require an AC_DEFUN_ONCE macro, > then it is easy to fix your c

Re: expand-before-require bug

> configure.ac:50: warning: AC_REQUIRE: `gl_MULTIARCH' was expanded before it > was > required > m4/printf.m4:811: gl_PRINTF_ENOMEM is expanded from... > m4/vasprintf-posix.m4:7: gl_FUNC_VASPRINTF_POSIX is expanded from... > m4/gnulib-comp.m4:45: gl_INIT is expanded from... > configure.ac:50: th

Re: expand-before-require bug

> - macros defined with AC_DEFUN_IDEMPOTENT are *known* to be expandable > any number of times, hence they may be both invoked and required, > > - macros defined with AC_DEFUN_ONCE are *known* to be expandable only > once, hence the recommendation for them is to AC_REQUIRE them, Do w

Re: expand-before-require bug

Eric Blake wrote: > > I think you should also deprecate AC_GNU_SOURCE in autoconf. > > It already is deprecated, as of autoconf 2.62 You're right. Sorry, my mistake. Bruno

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/22/2009 5:31 AM: > Eric, >> * modules/errno (configure.ac): Require, rather than expand, >> gl_HEADER_ERRNO_H. >> * m4/errno_h.m4 (gl_HEADER_ERRNO_H_BODY): Merge... >> (gl_HEADER_ERRNO_H): ...into this macro, and use AC_

Re: expand-before-require bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/22/2009 4:42 AM: > Hi Eric, > > [CCing bug-autoconf. This is a reply to > ] > >> * gnulib-tool (func_dest_tmpfilename, func_create_testdir): Using >>

Re: expand-before-require bug

Eric, I wrote: > - provide a documented way to avoid the warning for a particular macro, > I much prefer to have a macro which can be both invoked and required, > even if it requires one more line of code to write it down, than to have > a macro with restricted use. Here's a concret

Re: expand-before-require bug

Hi Eric, > * modules/errno (configure.ac): Require, rather than expand, > gl_HEADER_ERRNO_H. > * m4/errno_h.m4 (gl_HEADER_ERRNO_H_BODY): Merge... > (gl_HEADER_ERRNO_H): ...into this macro, and use AC_DEFUN_ONCE to > enforce that all clients require it. This change is a step backwards. It makes th

Re: expand-before-require bug

Hi Eric, [CCing bug-autoconf. This is a reply to ] > * gnulib-tool (func_dest_tmpfilename, func_create_testdir): Using > obsolete AC_GNU_SOURCE causes out-of-order expansion; avoid it, > and rely solely on gl_USE_SYSTEM_EXTENSIO

Re: expand-before-require bug

Eric Blake byu.net> writes: > As of this morning, autoconf.git now warns you on instances of expand-before- > require (aka ordering bugs in older autoconf, and redundant output when using > bleeding edge autoconf). I'm working on a series of patches to reduce the > number of warnings we trigge

Re: expand-before-require bug

Eric Blake byu.net> writes: > > As of this morning, autoconf.git now warns you on instances of expand-before- > require (aka ordering bugs in older autoconf, and redundant output when using > bleeding edge autoconf). I'm working on a series of patches to reduce the > number of warnings we tri

expand-before-require bug

As of this morning, autoconf.git now warns you on instances of expand-before- require (aka ordering bugs in older autoconf, and redundant output when using bleeding edge autoconf). I'm working on a series of patches to reduce the number of warnings we trigger, starting with this one: configure.