On Mon, Mar 09, 2026 at 07:03:36PM +0100, Bruno Haible wrote: > Zack Weinberg 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 > > +1. The first time I saw someone use > > AUTOPOINT=true autoreconf > > as a way to tell autoreconf not to invoke 'autopoint', I found it strange. > The --exclude option definitely will lead to more understandable shell > scripts and build recipes.
But the actual result will be a mixture of scripts and build recipes with some using AUTOPOINT=true and some using --exclude=autopoint to achieve the same results. So now autoconf users have to know both options. I don't think that necessarily makes things "more understandable". Going back to Zack's original post: "squeezing features into what would otherwise be a release candidate is always a risk, and we don't have comprehensive tests for autoreconf." Is duplicating a subset of functionality from a longstanding autoreconf feature really worth this risk? Cheers, Nick
