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

[Jim Meyering]

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.