>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes:
Martin> I agree that the level of quoting in all autoconf macros
Martin> should be consistent. This may be worth breaking
Martin> compatibility with current configure.in's. But incompatible
Martin> changes should be reserved for major version changes like 3.0.
You're talking of extreme situations. Most packages use literals as
argument to AC_OUTPUT, and this is what I am concentrating on.
I still have to check your report in details though.
AD> Defining macros in configure.in is not a good idea IMHO. Yet as
AD> an argument of another macro, this is sadism :)
Martin> This would not be the case if m4/autoconf was reasonable.
Martin> Many macro calls contain "code" as an argument. That code can
Martin> in turn contain m4 macro calls. So why not also `define'?
Martin> But this is just philosophy.
Agreed.
I could not come with unbeatable arguments to prove you're wrong, it's
only a feeling, but a strong one.
configure.in is addressing an issue which should be almost entirely
declarative, and let it be only for this reason, facts and rules
should be separated.
Martin> I realize the real world of autoconf is already horribly ugly,
Naaah, it has its own esthetics, which is very much like modern art,
indeed :)
Martin> and you have to make engineering solutions that work, never
Martin> mind the esthetics.
We are improving this factor. Some day your configure.in will be
beautiful :)
Martin> And I'm willing to make reasonable changes to my configure.in
Martin> to incorporate improvements in autoconf.
Thanks. Conversely, we will certainly adopt many of your
specificities, so in the medium term, we will come up with better
Autoconves and Xemacs-configure :)
Akim
