./bootstrap required [Re: [libvirt] fix two "make syntax-check" failures

Cole Robinson crobinso at redhat.com
Thu Jul 9 22:12:06 UTC 2009


Daniel P. Berrange wrote:
> On Thu, Jul 09, 2009 at 08:39:32PM +0200, Jim Meyering wrote:
>> Jim Meyering wrote:
>> ...
>>> I had fixed the latter in gnulib (now that main.mk comes
>>> from there), but had forgotten to tell libvirt to use
>>> the latest version of gnulib, in order to get that fix.
>>> To do that, I ran "git syncsub" (where syncsub is an alias:
>>> syncsub = submodule foreach git pull origin master)
>>> then git commit -a.
>>>
>>> Here are the two patches I'm about to push:
>> ...
>>> >From 72978b978991f106dc0e36b10a942d9040a1df00 Mon Sep 17 00:00:00 2001
>>> From: Jim Meyering <meyering at redhat.com>
>>> Date: Thu, 9 Jul 2009 20:02:31 +0200
>>> Subject: [PATCH 2/2] build: update from gnulib, for latest maint.mk
>>>
>>> * gnulib: Update submodule to latest.
>>> This fixes the make syntax-check failure whereby sc_po_check
>>> would complain about cfg.mk.
>>> ---
>>>  .gnulib |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/.gnulib b/.gnulib
>>> index 1203e8d..b653eda 160000
>>> --- a/.gnulib
>>> +++ b/.gnulib
>>> @@ -1 +1 @@
>>> -Subproject commit 1203e8d1f62dec3d2436dffadd5c20793cf84366
>>> +Subproject commit b653eda3ac4864de205419d9f41eec267cb89eeb
>> Note how that patch changed the .gnulib submodule.
>> When you pull such a change, you have to know to run ./bootstrap
>> to pull in updated-from-gnulib files.
> 
> Yeah, this is the kind of scenario where I think it'd be good to have
> autogen.sh somehow notice the .gnulib submodule hash changed, and 
> automatically run bootstrap to re-sync.
> 

I actually just had a brief WTF moment, tripping up on the need to run
./bootstrap with a fresh checkout. autogen.sh fails pretty spectacularly in
that case: I can imagine it would send a first time user running for the hills.

+1 to any way of integrating this with autogen.sh (or at least clearly warning
the user if the necessary steps haven't been taken).

- Cole




More information about the libvir-list mailing list