[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnulib] Re: modules/{sysexits,poll}: syntax nits
From: |
Simon Josefsson |
Subject: |
[Bug-gnulib] Re: modules/{sysexits,poll}: syntax nits |
Date: |
Mon, 03 Nov 2003 22:24:13 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) |
Jim Meyering <address@hidden> writes:
> Simon Josefsson <address@hidden> wrote:
>> Jim Meyering <address@hidden> writes:
>>> These changes make it so all of the modules files use the
>>> same syntax for AC_SUBST'd variable names.
>>> Anyone object?
>>
>> Not really, although the Autoconf manual only mention @FOO@ in
>> relation to AC_SUBST, not $(FOO).
>
> About 6 months ago, Alexandre Duret-Lutz mentioned somewhere that
> we should now start using $(FOO) in place of the then-obsolete (but
> still-supported) @FOO@ notation.
OK. (Added to CC list.)
>> I recall getting a warning in some
>> version of some tool (can't recall the details, sorry) for using
>> $(FOO) instead of @FOO@, but I haven't seen it lately.
>
> Coreutils have had no problems since the switch back in April.
> Maybe you were using some older version of automake?
> The manual I use describes AC_SUBST like this
> (without mention the @FOO@ notation):
>
> `AC_SUBST'
> The first argument is automatically defined as a variable in each
> generated `Makefile.in'.
> ...
Ah, right, I was looking in the Autoconf manual:
- Macro: AC_SUBST (VARIABLE, [VALUE])
Create an output variable from a shell variable. Make `AC_OUTPUT'
substitute the variable VARIABLE into output files (typically one
or more `Makefile's). This means that `AC_OUTPUT' will replace
instances of address@hidden@' in input files with the value that the
shell variable VARIABLE has when `AC_OUTPUT' is called. This
value of VARIABLE should not contain literal newlines.
Perhaps it would be useful to mention the $(FOO) vs @FOO@ issue more
prominently in the Automake manual, if it is important (*), since most
people (assuming most people are like me) just do pattern-matching
against examples when learning from reference manuals.
Personally, I have been using @FOO@, but I'll change as well.
(*) I'm not sure I understand what difference using one over the other
would have.