>>>>> "AD" == Akim Demaille <[EMAIL PROTECTED]> writes:
AD> dnl CPP_MAKEFILE(CPPFLAGS,filename)
AD> define([CPP_MAKEFILE],
AD> [echo creating $dir/[$2]
AD> $CPP -I. -I${top_srcdir}/src [$1] junk.c \
AD> dnl Delete line directives inserted by $CPP
AD> | sed -e 's/^\#.*//' \
AD> dnl Delete spurious blanks inserted by $CPP
AD> -e 's/^[[ ][ ]]*$//'\
AD> -e 's/^ / /' \
AD> dnl Delete blank lines
AD> | sed -n -e '/^..*$/p' \
AD> dnl Restore lines quoted above to original contents.
AD> | sed '/^\"/ {
AD> s/\\\([\"]\)/\1/g
AD> s/^[[ ]]*\"//
AD> s/\"[[ ]]*$//
AD> }' > Makefile.new
AD> chmod 444 Makefile.new
AD> mv -f Makefile.new [$2]
AD> ])dnl CPP_MAKEFILE
AD> BTW, your quoting is not homogeneous with that used in Autoconf. The
AD> rule is now one level of [] for each evaluation, ie. each pair of ().
AD> In particular in the macro above, no single occurrence of $1/$2 should
AD> be quoted.
I agree that the level of quoting in all autoconf macros should be
consistent. This may be worth breaking compatibility with current
configure.in's. But incompatible changes should be reserved for major
version changes like 3.0.
AD> *Yes* it means that that if you want to use a macro name as $1 it must
AD> be quoted twice at the top level. But that's the price the pay for
AD> uniformity. Double-quoting macros are a pain.
I must admit I never acquired intuition about levels of quoting. When
defining new macros, I would add levels of quoting and compared the
source with the generated configure script. I think this problem is
endemic to many programming languages that have multiple levels of
interpretation. Double backquotes in lisp and the seemingly infinite
sequences of backslashes needed in some shell scripts are examples.
AD> | Regarding your comment about defining a macro inside AC_OUTPUT: it's a
AD> | general principle of good software engineering to define everything as
AD> | close to its use and in as small a scope as possible. So logically,
AD> | if it's only used in AC_OUTPUT, what better place to define it?
AD> In m4/cpp-makefile.m4. Defining macros in configure.in is not a good
AD> idea IMHO. Yet as an argument of another macro, this is sadism :)
This would not be the case if m4/autoconf was reasonable. Many macro
calls contain "code" as an argument. That code can in turn contain
m4 macro calls. So why not also `define'?
But this is just philosophy. I realize the real world of autoconf is
already horribly ugly, and you have to make engineering solutions that
work, never mind the esthetics. And I'm willing to make reasonable
changes to my configure.in to incorporate improvements in autoconf.
Martin
