Re: Please test autoreconf from zack/autoreconf-exclude branch

(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 runni=
ng
>> something it shouldn't, and they look at autoreconf --help, the --exc=
lude
>> 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=E2=80=99t* clear at all, even with the =E2=80=
=9Cmay be
used to override=E2=80=9D wording.  It is quite plausible to me that som=
eone
would assume this feature is limited to picking *alternative
implementations* of the =E2=80=9Crespective tools,=E2=80=9D i.e. that wh=
atever is
picked, it has to actually do what the command=E2=80=99s supposed to do.

I could address that with another sentence, but, like I said, I think
people will not notice that sentence, because they=E2=80=99re too focuse=
d 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=E2=80=99t
argues that this is a real problem and *not* one that=E2=80=99s adequate=
ly
addressed by the existing mechanism, albeit perhaps only because
people don=E2=80=99t know about it.

I didn=E2=80=99t invent the --exclude option; OpenEmbedded has been carr=
ying a
patch for it for several years.  I=E2=80=99d like to ask the original au=
thor
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=3Dtrue in the environment?  And, if you did know that, do you
remember why that approach didn=E2=80=99t work for OE?

zw