If you look at the
gawk source in the
repository, you will notice that it includes files that are automatically
generated by GNU infrastructure tools, such as Makefile.in from
automake and even configure from
This is different from many Free Software projects that do not store the derived files, because that keeps the repository less cluttered, and it is easier to see the substantive changes when comparing versions and trying to understand what changed between commits.
However, there are two reasons why the
likes to have everything in the repository.
First, because it is then easy to reproduce any given version completely, without relying upon the availability of (older, likely obsolete, and maybe even impossible to find) other tools.
As an extreme example, if you ever even think about trying to compile,
oh, say, the V7
awk, you will discover that not only do you
have to bootstrap the V7
yacc to do so, but you also need the
lex. And the latter is pretty much impossible to bring up
on a modern GNU/Linux system.110
(Or, let’s say
gawk 1.2 required
in 1989 and that there was no awkgram.c file in the repository. Is
there a guarantee that we could find that
bison version? Or that
it would build?)
If the repository has all the generated files, then it’s easy to just check
them out and build. (Or easier, depending upon how far back we go.
And that brings us to the second (and stronger) reason why all the files
really need to be in
git. It boils down to who do you cater
gawk developer(s), or the user who just wants to check
out a version and try it out?
wants it to be possible for any interested
awk user in the
world to just clone the repository, check out the branch of interest and
build it. Without their having to have the correct version(s) of the
That is the point of the bootstrap.sh file. It touches the
various other files in the right order such that
# The canonical incantation for building GNU software: ./bootstrap.sh && ./configure && make
will just work.
This is extremely important for the
gawk maintainer would argue that it’s also
important for the
gawk developers. When he tried to check out
xgawk branch112 to build it, he
couldn’t. (No ltmain.sh file, and he had no idea how to create it,
and that was not the only problem.)
He felt extremely frustrated. With respect to that branch,
the maintainer is no different than Jane User who wants to try to build
master from the repository.
Thus, the maintainer thinks that it’s not just important, but critical, that for any given branch, the above incantation just works.
What are some of the consequences and/or actions to take?
PATHand just did:
wget http://ftp.gnu.org/gnu/package/package-x.y.z.tar.gz tar -xpzvf package-x.y.z.tar.gz cd package-x.y.z ./configure && make && make check make install # as root
Most of the above was originally written by the maintainer to other
gawk developers. It raised the objection from one of
the developers “… that anybody pulling down the source from
git is not an end user.”
However, this is not true. There are “power
who can build
gawk (using the magic incantation shown previously)
but who can’t program in C. Thus, the major branches should be
kept buildable all the time.
It was then suggested that there be a
cron job to create
nightly tarballs of “the source.” Here, the problem is that there
are source trees, corresponding to the various branches! So,
nightly tar balls aren’t the answer, especially as the repository can go
for weeks without significant change being introduced.
git server can meet this need. For any given
branch named branchname, use:
to retrieve a snapshot of the given branch.
We tried. It was painful.
There is one GNU program that is (in our opinion)
severely difficult to bootstrap from the
git repository. For
example, on the author’s old (but still working) PowerPC macintosh with
Mac OS X 10.5, it was necessary to bootstrap a ton of software, starting
git itself, in order to try to work with the latest code.
It’s not pleasant, and especially on older systems, it’s a big waste
Starting with the latest tarball was no picnic either. The maintainers
had dropped .gz and .bz2 files and only distribute
.tar.xz files. It was necessary to bootstrap
A branch created by one of the other developers that did not include the generated files.