(consolidating some replies)

On Mon, Mar 9, 2026, at 2:18 PM, Nick Bowler wrote:
> On Mon, Mar 09, 2026 at 01:14:38PM -0400, Zack Weinberg wrote:
>> On Wed, Mar 4, 2026, at 6:51 PM, Nick Bowler wrote:
>> > Why implement a new option for this?
>>
>> Discoverability.  If someone's having a problem with autoreconf running
>> something it shouldn't, and they look at autoreconf --help, the --exclude
>> option will be right there.
>
> I do think the sentence in the Autoconf manual is better than the
> sentence in the autoreconf --help text, because it actually says
> what the variables are for:
>
>    The environment variables AUTOM4TE, AUTOCONF, AUTOHEADER, AUTOMAKE,
>    ACLOCAL, AUTOPOINT, LIBTOOLIZE, INTLTOOLIZE, GTKDOCIZE, M4, and MAKE
>    may be used to override the invocation of the respective tools.
>
> Surely it does not need to be explained that the ability to choose
> the command which is run also includes the ability to choose a command
> which does nothing.

Honestly, I think that *isn’t* clear at all, even with the “may be
used to override” wording.  It is quite plausible to me that someone
would assume this feature is limited to picking *alternative
implementations* of the “respective tools,” i.e. that whatever is
picked, it has to actually do what the command’s supposed to do.

I could address that with another sentence, but, like I said, I think
people will not notice that sentence, because they’re too focused on
looking for an *option* to make autoreconf do what they want.

> Is duplicating a subset of functionality from a longstanding
> autoreconf feature really worth this risk?

Fair question; just the number of tests I feel I need to write before
landing the branch is making me reconsider whether this ought to be
put into 2.73.  However, against that, the number of complaints we got
since 2.70 about autoreconf trying to run tools that it shouldn’t
argues that this is a real problem and *not* one that’s adequately
addressed by the existing mechanism, albeit perhaps only because
people don’t know about it.

I didn’t invent the --exclude option; OpenEmbedded has been carrying a
patch for it for several years.  I’d like to ask the original author
of that patch to chime in at this point.  Ross, can you remember why
you originally wrote this patch?  In particular, do you remember if
you knew that much the same effect could be had by setting e.g.
AUTOPOINT=true in the environment?  And, if you did know that, do you
remember why that approach didn’t work for OE?

zw

Reply via email to