Re: autogen?

[Maciej Stachowiak <mstachow@mit.edu>]

jimb@red-bean.com writes:
> 
> I've been fiddling around a bit with the GTK+ and GLIB trees, and at a
> first glance, I like the way they handle rebuilding Makefile.in,
> configure, and such with an `autogen.sh' script.
> 
> How would folks feel about switching Guile to this system?  Among
> folks who have used both Guile's way and GTK+'s way, which do you
> prefer?
> 

I've accessed both Guile and GTK+ through (read-only) CVS as mostly a
user, and I've worked on scwm under both policies. We now use the
gtk-like policy. Checking in machine-generated files is a pain for
both developers (who have to know when these change) and for users
(who may get pointless conflicts sometimes, especially given
automake's buggy treatment of the TAR variable, which Tom Tromey is
still leaning against fixing).

Not doing so (and providing autogen.sh) is a slight overhead for users
getting things from CVS - they need auto{make,conf} and libtool
installed. However, I feel that users getting stuff from CVS have
willingly signed on for a bit of potential pain, and the
developers/maintainers should not do extra work on their account. This
is not necessarily an issue for nightly snapshots, however; in the
scwm snapshot script we run autogen.sh as part of the snapshot-making
process (ours is not set up to run configure, unlike gtk+'s) so
snapshot users do not need the various auto-tools.

Overall, having had experience with both, I am in favor of the
gtk-like policy with the modification that autogen.sh should not call
configure (I dislike that behavior because I often want to run
./configure --help to see the available options before I run
configure, and because it makes the snapshot trick described above
harder).

 - Maciej