Re: autoconf: dead-lock? at how many locations???

[Ralf Wildenhues]

Hello Frank,

* address@hidden wrote on Wed, Apr 14, 2010 at 03:34:38PM CEST:
> I did try to make an autoconf-installation from source.
> I did fail because of I need autoconf to make autoconf.

this used to be different; the (at the time) CVS tree of Autoconf used
to also have the files generated from Autoconf and Automake tools, so
that one could run ./configure right away.  However, there were problems
with that, and they were bothering typical maintenance:

- these generated files need to be kept in sync in the repository, and
  using the same Automake version by all contributors was necessary,

- even with generated files in version control, the version control
  system would not guarantee correctly ordered time stamps, so that an
  autoconf run might still happen to be triggered by 'make', even when
  it was not technically necessary.  This would, in your case, then
  still lead to an error.  (The speed of git hides this issue often.)

There are more reasons against keeping generated files in version
control such as bloated diffs (and a couple for doing so), 'info
Automake CVS' has a discussion of the topic.  Both issues above can be
worked around by using special-case tools, but then you start to get to
the point where you're making things harder for a regular developer and
the Autoconf maintainer, only to make it easier for the new developer.
There was at the time a conscious decision to not go this way in
Autoconf, supported by the notion that virtually all systems typically
used for development also distribute a fairly recent Autoconf package
already.

As an example, the Automake tree still does it the other way (but you
still have to run ./bootstrap after the initial checkout there).

Hope that helps.

Cheers,
Ralf