Hi Eric, * Eric Blake wrote on Tue, Nov 11, 2008 at 08:16:55PM CET: > I'm debating about committing this patch. It shaves off a lot of blank lines > in configure output. But I also found at least one use case in the wild that > changes semantics if I commit it: > http://lists.gnu.org/archive/html/bug-coreutils/2008-11/msg00049.html
Ouch. Are you certain that removing this newline is really worth the price of a silent incompatibility? > By making AC_DEFINE no longer force a leading newline, users that define a > shell variable then call AC_DEFINE on the same line have become localized > assignments, rather than persistent. How much should we worry about breaking > existing scripts, given that I did not see much common use of > var=val AC_DEFINE > in my searching? We should worry very much about any kind of valid construct in user's scripts, IMVHO. If you persist in it, how about letting autoconf warn about instances of ^[\t ]*[^\t ]+[\t ]*\<AC_DEFINE in the input (inconsistent regex notation)? I fear that the number of hard-to-detect incompatibilities is really growing a bit more than we would like, in the current development tree. Cheers, Ralf
