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
signature.asc
Description: OpenPGP digital signature
