Cole Robinson wrote:
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(a)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).
Actually, we can do even better.
Run it via "make".
There's only one problem when doing it that way:
Whenever you rerun bootstrap, you also have to rerun autogen.sh.
And to automatically run autogen.sh, you need to know what
(if any) command line arguments the user would have selected,
e.g., --prefix or other ./configure options.
IMHO, this is a good argument for changing autogen.sh so that
(like many other autogen scripts) it tells the user to run
not "make" directly but "./configure ... && make".
Anyhow, if you don't mind rerunning ./autogen.sh with *no*
options, here's how to make it so after pulling a gnulib submodule
update, the next "make" will automatically detect that and run
both ./bootstrap and autogen.sh for you.
[currently this works only from a srcdir build]
diff --git a/cfg.mk b/cfg.mk
index 736f7c0..8750751 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -230,3 +230,16 @@ sc_libvirt_unmarked_diagnostics:
# We don't use this feature of maint.mk.
prev_version_file = /dev/null
+
+ifeq (0,$(MAKELEVEL))
+ _curr_status = .git-module-status
+ __dummy := $(warn MAKELEVEL = $(MAKELEVEL))
+ _submodule_check := \
+ $(shell t=$$(git submodule status); \
+ test "$$t" = "$$(cat $(_curr_status) 2>/dev/null)" \
+ || { test -w /dev/tty && echo running bootstrap...>/dev/tty; \
+ ./bootstrap && echo "$$t" > $(_curr_status); \
+ test -w /dev/tty && echo running autogen.sh...>/dev/tty; \
+ ./autogen.sh; \
+ })
+endif