On Mon, 2026-03-09 at 15:57 -0400, Zack Weinberg wrote: > (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 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’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? 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=95b67de37447d7c30164eeec818429f4b34e6fc4 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=true" 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 "--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 += "--exclude=aclocal --some-other-option" vs: EXTRA_AUTORECONF_ENV += "ACLOCAL=true" EXTRA_AUTORECONF += "--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
