[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: M4 syntax $11 vs. ${11}
From: |
Ralf Wildenhues |
Subject: |
Re: M4 syntax $11 vs. ${11} |
Date: |
Wed, 31 Jan 2007 20:18:36 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Hello Eric,
Allow me to address specific points only, rather than the larger picture
of where to finally go.
* Eric Blake wrote on Tue, Jan 30, 2007 at 02:04:51PM CET:
> According to Ralf Wildenhues on 1/29/2007 11:44 AM:
>
> > The Coding Style ends up being inconsistent with
> > $[#] where it's necessary to quote the hash,
>
> You missed the earlier line that recommended address@hidden:@] instead of
> $[#] for
> the sake of syntax highlighting, even though both have the same effect.
Right.
> > $[1] where either character could be quoted,
> > [$]{1...} vs. $[{1...}] vs. $[{]1...}
> > where the first is inconsistent with the
> > previous examples, and the others are ugly,
>
> What about a slightly different approach:
>
> When in a single-quoted context, use an empty quote to separate the $ from
> the next character:
> AC_FOO([ address@hidden:@ ]) to avoid $# as well as comment, use a
> quadrigraph
> AC_FOO([ $[]1 ]) instead of $1
> AC_FOO([ $[]{1...} ]) instead of ${1...}
>
> and when in a double-quoted context (less common, since we recommend one
> level of quotes per parentheses), use an inverted empty quote to break the
> string into two parts:
> AC_FOO([[ $][# ]]) no quadrigraph necessary
> AC_FOO([[ $][1 ]])
> AC_FOO([[ $][{1...} ]])
Barring all other questions, this looks consistent to me.
> > IMHO, it's not a good idea to not "practice what we preach" in any
> > direction: either have the code be more cautious than the documentation,
> > or vice versa.
>
> Unfortunately, I think existing code in autoconf alone is full of several
> styles. Would it be worth my time to also prepare a mechanical patch that
> tries to convert existing uses into a single style?
I'd probably be in the "only for new code, follow this" boat, to provide
bug-for-bug compatibility with buggy user scripts.
> Or maybe we just give up, and flat out document that as long as autoconf
> supports both M4 1.4.x and 2.0 simultaneously, m4's --warn-syntax option
> must not be used. Then only the line in m4sugar that uses changesyntax to
> cripple M4 2.0's ${1} parsing is needed, and we can ignore false
> positives.
Is that even true? What about code that is read before AC_INIT? What
about code that uses `define' not `m4_define'?
I tried your warnings now:
cat >aclocal.m4 <<\EOF
AC_DEFUN([Y], [${1}])
define([Z], [${1}])
EOF
cat >configure.ac <<\EOF
AC_INIT
AC_DEFUN([X], [${1}])
EOF
M4=m4\ --warn-syntax autoconf
| m4:aclocal.m4:1: Warning: semantics of `${1...}' in `Y' will change
Why do I get only one warning, and only get the next one, once I fix the
first? Fixing one-by-one is very frustrating for users.
Cheers,
Ralf