Daniel P. Berrange wrote:
On Fri, Jul 10, 2009 at 09:42:10AM +0200, Jim Meyering wrote:
> Cole Robinson wrote:
>
> > Daniel P. Berrange wrote:
> >>>> 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".
No I like the way autogen.sh currently works. bootstrap is logically
a part of what autogen.sh should be doing, not part of 'make' rules.
> 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.
Running autogen.sh without options is going to causing just as much
pain & confusion, because it is pretty common to give options to
autogen.sh particularly to change the install loction.
Ok, then I'll arrange for "make" to fail in that case,
and to give a diagnostic saying "run autogen.sh".
And autogen.sh will run bootstrap, if/when needed.
So there will no longer be a separately-run bootstrap step.