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
