Daniel P. Berrange wrote:
On Wed, Jul 08, 2009 at 12:58:11PM +0200, Jim Meyering wrote:
Daniel P. Berrange wrote: ...
From: Jim Meyering <meyering@redhat.com> Date: Tue, 7 Jul 2009 11:22:52 +0200 Subject: [PATCH 5/7] make .gnulib a submodule
This makes it so we record (via a git submodule) a snapshot of whatever version of gnulib we're using, and none of gnulib sources are in the libvirt repository. The result is that we have as much reproducibility as when we version-controlled imported copies of the gnulib sources, but without the hassle of the manual process we used when syncing with upstream.
Note that when you clone libvirt, you get only the libvirt repository, but when you first run ./bootstrap, it clones gnulib (at the SHA1 recorded via the submodule), creating the .gnulib/ hierarchy. Then, the bootstrap script runs gnulib-tool to populate gnulib/ with the files that make up the selected modules.
I think perhaps we should wire this into the autogen.sh script. People are used to just cloning a repository and running autogen.sh to get things setup, so it would cause unneccessary confusion to also require them to run bootstrap seprately.
One reason not to do this (at least not unconditionally) is that it takes pretty long. I've just timed it at 31 seconds, even though everything is already downloaded. That happens to be the same duration (to the second!) of the existing ./autogen.sh script.
I was thinking that you'd only do it if you hadn't already pulled the gnulib sub-module, or if it was out of date.
One situation in which it must be run is e.g., right after the initial clone, when is when .gnulib/ does not exist. Or after someone removes .gnulib manually. ./bootstrap must also be run any time you change (or pulling the latest changes) the list of selected gnulib modules or gnulib-tool options. Likewise, if you pull a change that selects a newer version of .gnulib (updates libvirt to use a newer gnulib snapshot), you'll have to run it. There's probably a way to automate all of that, but I haven't tried.