[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: M4 syntax $11 vs. ${11}
From: |
Eric Blake |
Subject: |
Re: M4 syntax $11 vs. ${11} |
Date: |
Mon, 29 Jan 2007 07:08:36 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Paul Eggert on 1/28/2007 2:40 AM:
> Eric Blake <address@hidden> writes:
>
>> Here's an updated (and smaller) patch that makes CVS autoconf happy with
>> branch-1_4 of M4, after today's commit that adds --warn-syntax to M4.
>
> In looking at this patch, I wonder: why not have M4 2.0 use the
> extension only if the input is of the form ${DIGITSTRING}, where
> DIGITSTRING is a sequence of one or more ASCII digits? That way, we
> needn't change Autoconf's m4 code at all (though the documentation
> should still be changed, probably).
Because I was hoping that M4 2.0 could borrow a leaf from shell parsing,
and ALSO implement things like ${1-default} that is more compact than the
current ifelse(`$1',,`default',`$1') in M4 parlance.
Yes, this starts to cross over into more usages that interfere with shell
syntax, which is why my patch simply disables ${} parsing in M4 altogether
as the first step of m4sugar. That way, even Ralph's usage of ${1}
(instead of [$]1 or $[1]) will be unaffected. In other words, my patch
disables the new feature, then silences the six false positives that
result from running with --warn-syntax and ${} parsing disabled, rather
than forcing all uses that interfere with the new feature to be rewritten.
It is much more palatable than my first cut of the patch that had to
target more than 100 instances of ${} parsing across multiple projects.
>
> Very few shell scripts will contain usages like ${11} or ${0}, whereas
> lots of them will have usages like ${1-'x'}. If the M4 extension
> uses only a syntax that is unlikely to occur in a shell script,
> then we needn't worry about this issue so much.
Or, by disabling ${} parsing in M4 2.0, we likewise don't have to worry
too much. Most autoconf m4 snippets will be unaffected, except for the
few masochists that run a wrapper around m4 (like I did, to find the six
false positives in my patch, and to make sure no one was using $10 anywhere):
#!/bin/sh
exec path/to/m4 --warn-syntax "$@"
>
> I'm not so much worried about Autoconf proper here, as about macros in
> other places (like Gnulib) that will also be affected by this change.
That's the difference between this patch and my original one. The
original also required followup patches to automake, gnulib, and libtool,
just to perform autoreconf on CVS m4. This one, on the other hand, does
not - since ${} parsing is disabled in autoconf, then gnulib, automake,
and libtool can be used as is (well, libtool also had some false positives
when using m4 --warn-syntax, so I'm sending a patch there as well; but it
is much quieter than the earlier trigger on all instances of ${ in libtool).
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFvf/k84KuGfSFAYARAlH5AKCFkYk+RmLgKWi9oXuxh5v8kcmQOgCgk3Ap
KHXyL57OiUW3vDQjPYz6mBU=
=7YKO
-----END PGP SIGNATURE-----