-----BEGIN PGP SIGNED MESSAGE----- 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 encountered. > > 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 > EOF > > 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 [email protected] -----BEGIN PGP SIGNATURE----- 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 iEYEARECAAYFAklwhskACgkQ84KuGfSFAYDHpQCeM8Fx5frwK4loxoALvncKIUFR fy0An3d6bxekOUjOcjsFy6+SgUVrUW03 =ehhD -----END PGP SIGNATURE-----
