Re: bad m4 quotation?

[Ralf Wildenhues]

Hi Stepan,

* Stepan Kasal wrote on Tue, Apr 04, 2006 at 05:17:25PM CEST:
> 
> after Noah's excellent analysis, we have to decide which of the
> problems should be fixed.  Actually my opinion is exactly oposite:

:-) And my response has gotten too long, for which I apologize.
But anyway, here it is:

> On Tue, Apr 04, 2006 at 10:53:59AM +0200, Ralf Wildenhues wrote:
> > * Noah Misch wrote on Sun, Apr 02, 2006 at 08:32:17PM CEST:
> > > (Side note: the removal of double quotes is suspicious; it appears to 
> > > change
> > > behavior for weird tag names.  This may not matter too much.)
> > 
> > Let's not worry about that until we get a report to this end.
> 
> Though tags cannot contain shell wildcards, they can probably contain
> parentheses.  When I removed the double quotes, I gained nothing.
> So I think it wouldn't matter if we put them back.

OK, so let's put them back.

> > > Long term, we might want to diagnose and forbid AC_CONFIG_<FOO>S tags 
> > > containing
> > > characters special to the shell, which would also catch macro calls.  For 
> > > now,
> > > let us fix this regression by treating the first argument to 
> > > AC_CONFIG_COMMANDS
> > > as we did in Autoconf 2.59:
> > 
> > Yes.  Please apply, and thanks for analyzing and debugging this!
> 
> I don't like this patch.
> 
> IMHO, the small regression is worth the increased consistency.

I respectfully disagree here.  The patch may not be nice, and it may not
be the one we should apply, but the regression it fixes is important.

> (But I'm biased here, because I'm very proud of my rewrite of status.m4.  :-)

Certainly.  I may be biased here as well: I spent time actually tracking
this down.  When it hits users, and yes, there AX_PREFIX_CONFIG_H macro
is used in some packages, lots of them will not be in the position to
fix the macro; most likely, the connection between this advanced macro
and the weird error message will prevent them from reporting it to some
person that can fix it.  I mean, just look at the example where it came
up: it was in some obscure m4 macro file in a subpackage of a package,
and the reporter was a mere user of that package.  So we're actually
talking about 4 indirections user -> maintainer -> maintainer of
subpackage -> author of macro (-> autoconf list), until someone can be
expected to know what is happening.  I'm not saying someone earlier in
that chain may fix this, but it's sensible not to assume so.  (Before
you'll argue "yes, but the end user should never run autotools anyway"
now, remember that a mere timestamp screwup may trigger this for the
innocent end user.)

So no, I don't think this regression is tolerable.

Every time you choose to change or withdraw a published interface, it's
wise to go back and slap both the creator of the interface and yourself
in the face.  If they happen to be two separate persons, then don't take
this literally, but figuratively, please.  And promise to yourself that
next time you will think harder when designing a new interface.
(I wrote something similar once as advice to Libtool users that decide
to change their library interfaces.  And I had to go through it before
myself, too.)

AC_CONFIG_COMMANDS is much too widely used to be changed, IMVHO.  Please
invent something new if you must, but let's support what's out there if
we can, easily.  (And if Noah and I are overridden in our opinion, this
regression should be documented, including a rationale in NEWS.)

> Or, at least, I'd do something like:
> 
> ac_config_[]m4_tolower([$1])="$ac_config_[]m4_tolower([$1]) dnl
> dnl For historical reasons, treat command tag names differently:
> m4_if([$1], [COMMANDS], [$2], [m4_normalize([$2])])"

Oh, I certainly would not mind a "nicer" patch.  So feel free to post
one, and we'll look at it.  ;-)

Cheers,
Ralf