On 11/21/2011 07:47 AM, Gary V. Vaughan wrote:
> Until now, libtool sources have used braced variable names
> seemingly at random! Almost always the braces are just noise, so
> remove all the unnecessary ones.
> * cfg.mk (sc_useless_braces_in_variable_derefs): New syntax
> check rule to ensure we only reintroduce braced variable
> dereferences if they are followed by a valid variable name
> character.
> build-aux/general.m4sh, build-aux/git-hooks/commit-msg,
> build-aux/ltmain.m4sh, build-aux/options-parser, configure.ac,
> libltdl/configure.ac, m4/libtool.m4, m4/ltdl.m4,
> m4/ltoptions.m4, tests/defs.m4sh, tests/demo-nopic.test,
> tests/depdemo/configure.ac, tests/flags.at, tests/link.test,
> tests/objectlist.test, tests/quote.test, tests/static.at: Remove
> spurious braces.
> 
> +++ b/build-aux/ltmain.m4sh

> @@ -152,7 +152,7 @@ exec_cmd=
>  # Append VALUE to the end of shell variable VAR.
>  func_append ()
>  {
> -    eval "${1}=\$${1}\${2}"
> +    eval "$1=\$$1\$2"

Not necessarily correct.  One of the reasons for using ${1} in any m4
code that comprises the m4_define() definition of a macro is that $1 is
replaced by an argument by m4 in expanding the macro, while ${1} is
preserved unchanged through m4 expansion to be saved for the resulting
shell code.  I fear that your global search-and-replace may have been
too eager in m4-related files, but haven't read it closely to check for
sure; even if it didn't, the stylistic convention of ${1} for shell
expansion vs. $1 for m4 expansion made the file slightly easier to maintain.

-- 
Eric Blake   ebl...@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to