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

Nick Bowler <[email protected]> Mon, 9 Mar 2026 14:18:56 -0400
Newsgroups dev.linux.lists.distributions
Message-ID <k655rugxzjvt4tb5o3kc2zos6l7oz3ooqbfuw5j7yl2ls7miud@d7x637tpydpa>
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, instead of using the existing
> > environment variables which have been supported by autoreconf
> > since 2001?
> 
> 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.  The --help text does also mention the
> environment variables, but they're described as a way to control *what
> command* is run - like, in case you have autopoint somewhere off the default
> path - not as a way to control *whether* the commands are run.

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.

In my opinion having two different, documented methods to achieve
exactly the same result just makes things harder to explain, not
easier, especially when we're talking about a duplicating a feature
that autoreconf has already had for a quarter of a century.

Cheers,
  Nick