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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list