This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Regenerate with approved autotools version
- From: Paul Koning <paulkoning at comcast dot net>
- To: John Darrington <john at darrington dot wattle dot id dot au>
- Cc: Nick Alcock <nick dot alcock at oracle dot com>, Alan Modra <amodra at gmail dot com>, binutils at sourceware dot org
- Date: Wed, 19 Jun 2019 14:06:39 -0400
- Subject: Re: Regenerate with approved autotools version
- References: <20190614035346.GC22810@bubble.grove.modra.org> <87wohhj1am.fsf@esperi.org.uk> <20190619175927.5gclqb4raoglqmjo@jocasta.intra>
> On Jun 19, 2019, at 1:59 PM, John Darrington <john@darrington.wattle.id.au> wrote:
>
> On Wed, Jun 19, 2019 at 11:51:29AM +0100, Nick Alcock wrote:
> On 14 Jun 2019, Alan Modra uttered the following:
>
>> Someone apparently used a distro autotools.
>
>
> So I'll use an autoconf installed from the upstream tarball from now on.
>
> I seriously think, it'll be better all round if we remove all
> autogenerated files from the git repository. It will mean that a
> small extra overhead will be placed on developers, but this need
> be very small, and can be mitigated if we provide a recommended
> set of tools as an addendum. But this overhead I think will be
> greatly offset by the certainty that running "./configure; make" builds
> everything and that nothing is left in an inderterminate state.
Yes, but the trouble is that some project require exactly a single version of configure. It's one thing if you're actually modifying one of the input files and have to rerun autoconf. Many of us don't do that, and forcing every developer to keep around a suite of autoconf versions and tracking which one is right for which sandbox is a headache.
The other question is why autoconf Vx.y tag is different from Vx.y release, or why the tool is so fragile.
paul