[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_REQUIRE fails to ensure ordering of macros

From: Eric Blake
Subject: Re: AC_REQUIRE fails to ensure ordering of macros
Date: Fri, 16 Jan 2009 06:08:25 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20081209 Thunderbird/ Mnenhy/

Hash: SHA1

According to Bruno Haible on 1/16/2009 4:07 AM:
> Hi Eric,
> In <http://lists.gnu.org/archive/html/bug-gnulib/2009-01/msg00134.html> you 
> write:
>> This is the same issue as Bruno's
>> recently reported issue with gl_MULTIARCH.

> Thank you very much for looking into the problem. I see you analyzed it for
> a couple of days in
>   <http://lists.gnu.org/archive/html/bug-autoconf/2008-12/msg00039.html>
>   <http://lists.gnu.org/archive/html/autoconf-patches/2008-12/msg00063.html>

That last link was where I concluded, along with Paolo, that AC_REQUIRE
has no choice but to expand prerequisites prior to the outermost
AC_DEFUN'd macro.

> But the documentation of AC_REQUIRE
> <http://www.gnu.org/software/autoconf/manual/html_node/Prerequisite-Macros.html>
> says:
>   "To be more precise, the required macro is expanded before the outermost
>    defined macro in the current expansion stack."

And that documentation stands, although I will be further expanding it to
give the examples that we have uncovered, including advice on breaking the
expanded-before-indirectly-required problem that several people have

> and in your simplified example
> $ m4 -Ilib m4sugar/m4sugar.m4 - <<\EOF
> m4_init
> m4_defun([a],[in A
> ])
> m4_defun([b],[in B
> m4_require([a])])
> m4_defun([c],[in C
> m4_require([b])])
> m4_defun([outer], [pre
> a
> c
> post
> ])
> m4_divert[]dnl
> outer
> in B
> pre
> in A
> in C
> post
> the "outermost defined macro in the current expansion stack" for both 'a'
> and 'b' is 'outer' (no?), therefore both the 'in A' and 'in B' texts should
> come out before 'pre'.

Yes, that is the ultimate desired behavior (along with the additional
constraint that 'in A' comes before 'in B').  Current autoconf silently
fails this.  Making Autoconf 2.64 reorder things seems complex (it would
involve some tentative parses, followed by a retry of the overall
expansion), so it probably won't happen automatically.  But what I hope to
get done for autoconf 2.64 is at least issuing a warning that the
situation has occurred - by pointing out to the user that they expanded A
before it was indirectly required, then they should be able to find the
advice in the manual on how to refactor the dependency chain.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]