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

On Mon, 2026-03-09 at 15:57 -0400, Zack Weinberg wrote:
> (consolidating some replies)
>=20
> 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?
> > >=20
> > > Discoverability.=C2=A0 If someone's having a problem with autoreconf =
running
> > > something it shouldn't, and they look at autoreconf --help, the --exc=
lude
> > > option will be right there.
> >=20
> > 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:
> >=20
> > =C2=A0=C2=A0 The environment variables AUTOM4TE, AUTOCONF, AUTOHEADER, =
AUTOMAKE,
> > =C2=A0=C2=A0 ACLOCAL, AUTOPOINT, LIBTOOLIZE, INTLTOOLIZE, GTKDOCIZE, M4=
, and MAKE
> > =C2=A0=C2=A0 may be used to override the invocation of the respective t=
ools.
> >=20
> > 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.
>=20
> 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.=C2=A0 It is quite plausible to me that=
 someone
> would assume this feature is limited to picking *alternative
> implementations* of the =E2=80=9Crespective tools,=E2=80=9D i.e. that wha=
tever is
> picked, it has to actually do what the command=E2=80=99s supposed to do.
>=20
> 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 focused=
 on
> looking for an *option* to make autoreconf do what they want.
>=20
> > Is duplicating a subset of functionality from a longstanding
> > autoreconf feature really worth this risk?
>=20
> 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.=C2=A0 However, against that, the number of complaints we g=
ot
> 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 adequatel=
y
> addressed by the existing mechanism, albeit perhaps only because
> people don=E2=80=99t know about it.

I just replied to one of the other emails, not realising this one has
consolidated replies in it so sorry about that.

I think the existing functionality is unclear to people. At the very
least it would need better documentation but I also think it is a poor
interface for usability.

> I didn=E2=80=99t invent the --exclude option; OpenEmbedded has been carry=
ing a
> patch for it for several years.=C2=A0 I=E2=80=99d like to ask the origina=
l author
> of that patch to chime in at this point.=C2=A0 Ross, can you remember why
> you originally wrote this patch?=C2=A0 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?=C2=A0 And, if you did know that, do =
you
> remember why that approach didn=E2=80=99t work for OE?

I'm also from the OE world so I know a little about this patch. OE has
been carrying it for as long as I remember and I was there early on.
The first reference I could find is here from 2004:

https://git.openembedded.org/openembedded/commit/autoconf?id=3D95b67de37447=
d7c30164eeec818429f4b34e6fc4

The commit is broken with a decades old bitkeeper SCM translation but
the patch name looks right I'm fairly sure it dates from then in 2004
and we've carried it since. In the time since I'm happy to say we've
massively improved both our patch documentation and also our commit
messages but those don't help us in this case.

There are two reasons I can think of that this was probably done.
Firstly, "ACLOCAL=3Dtrue" can easily be misread as "enable aclocal" which
is the exact opposite of what it does.

Secondly, environment variables don't really feel like a proper
interface to the script and are harder for us to to inject. We have a
variable we can add parameters to our autoreconf calls to quite easily
and=C2=A0 "--exclude aclocal" is relatively obvious. If we need environment
variables as well as parameters, we need two variables and they're just
not as readable.

Perhaps it is better illustrated by looking at how we'd have to write
that in our metadata:

EXTRA_AUTORECONF +=3D "--exclude=3Daclocal --some-other-option"

vs:

EXTRA_AUTORECONF_ENV +=3D "ACLOCAL=3Dtrue"
EXTRA_AUTORECONF +=3D "--some-other-option"

I'd argue the latter is pretty horrible, which is why we've gone for
the former instead even if we had to carry a patch for 20+ years!

Cheers,

Richard