[libvirt] [PATCH] use gnulib via a submodule

[Jim Meyering]

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 at 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.