autoconf
[Top][All Lists]
Advanced

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

Re: Quick divert() 2.13/2.6x portability macro


From: Eric Blake
Subject: Re: Quick divert() 2.13/2.6x portability macro
Date: Sat, 28 Nov 2009 05:42:32 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Rasmus Lerdorf on 11/28/2009 12:35 AM:
> Having plenty of problems getting our old 2.13-based autoconf setup
> working under the new diversions in 2.6

There is no version 2.6, but there is 2.65.

What exactly are you trying to accomplish?  Without knowing your end goal,
I can't properly suggest a better alternative (and note that the better
alternative might mean using a different interface altogether).  It may be
better off to use the documented interface of m4_divert_text or a proper
use of AC_REQUIRE to cause the topological sorting necessary to achieve
your desired output order, without having to rely on raw diversions.

> AC_DEFUN([PHP_DIVERT],[
>    ifdef([AC_AUTOCONF_VERSION],
>      [
>        m4_case([$1],
>          [1],[divert(1001)],

Use of m4_divert is better than plain divert, in that it makes it obvious
that you are using a known m4 macro.  But using m4_divert at all is
generally asking for problems.  Also, I'm nearly complete with a patch for
the next autoconf that will complain loudly if you use a raw number
instead of a named diversion (and the manual will probably not document
how to create named diversions, so you would have to read the source code
for that).

> configure.in:4: error: m4_divert_pop(GROW): diversion mismatch:
> configure.in:4: m4_divert: 1001
> ../../lib/m4sugar/m4sugar.m4:3251: m4_divert_push: KILL
> autom4te: /usr/bin/m4 failed with exit status: 1

Have you read this thread yet?
http://lists.gnu.org/archive/html/bug-autoconf/2009-11/msg00045.html
http://lists.gnu.org/archive/html/bug-autoconf/2009-11/msg00057.html

That error message is symptomatic of breaking the diversion stack behind
autoconf's back.  In other words, autoconf expected to be in the GROW
diversion, but instead found itself in diversion 1001.  It may be possible
to avoid that error with a well-placed m4_divert([GROW]) before the end of
your file, but I can't even guarantee that that will give your desired
output ordering without seeing how you are using PHP_DIVERT.

> There must be a better way to map 2.13 behaviour to 2.6.  Has anybody
> tackled this?

I don't know what behavior you were expecting in 2.13, but that is so old
and interfaces have changed so much since then, including several bug
fixes, which, when not fixed, could lead to the silent output of an
invalid script for the majority of configure.ac that did not directly use
m4_divert in the first place.  Personally, I won't maintain compatibility
with anything older than 2.59; 2.13 is so old that it is not worth even
trying to make a configure.ac still work with something that old.  Since
m4_divert is already documented as a seldom-needed interface, I had no
qualms about making it more robust, even though it caused regressions for
the few people that were previously using it in an unsafe manner.  The
number of configure.ac that directly played with diversions is small
(perhaps PHP was the only culprit).  I'd like to help you fix that
breakage, but I can't/won't fix it until I know why the use of explicit
diversion management seems to be the only way to achieve your end goal.

The current manual states that playing with diversions is dangerous (it's
better to use AC_REQUIRE or m4_divert_text to a known diversion to
accomplish those goals instead), and I'm still working on a patch to make
the manual even more explicit that use of m4_divert without proper
maintenance of the diversion stack is discouraged, and that calling ANY
autoconf macro while the diversion stack is not in its usual state is
risking syntax errors in the resulting script.

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

Eric Blake             address@hidden
-----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/

iEYEARECAAYFAksRGrgACgkQ84KuGfSFAYDT/QCfeX2JaHPs1wC8NPw7zdVp3S2H
aWQAoI+vOcl0naYbQ/LRSmEghN23LHfP
=BdIi
-----END PGP SIGNATURE-----




reply via email to

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