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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list