Bleeding on the leading edge.

[hjstein@bfr.co.il (Harvey J. Stein)]

Erik <erik@msc.tamu.edu> writes:

 > autogen.sh is really nice when it works, but when it doesn't work
 > you're screwed. Kind of like plug and play for software.

Very much agreed.  I regularly have build problems with scwm, Guile, &
now GTK+.  It's getting to be a real pain in the ass to try to use all
these CVS repositories & new packages.  Between developers always
upgrading to the latest features of the latest packages, and quirks,
problems & changes with the auto* family, it seems like attempting to
upgrade any package requires a huge amount of upgrading & rebuilding.

Example:

I want to upgrade the scheme version of my doc extractor for scwm.  I
can't stand reading the code for the perl version, so I actually need
to run the perl version.  But to run it, I need a newer version of
perl & I need the perl text module.  Does it *really* need the new
perl?  Could the use of new features been avoided?  I don't know.

Continuing on, I wanted to build the latest version.  But, autoconf
failed because I did't have a new enough version of GTK+:

   checking for GTK - version >= 1.0.6... 
   *** An old version of GTK+ (1.0.4) was found.
   *** You need a version of GTK+ newer than 1.0.6. The latest version of
   *** GTK+ is always available from ftp://ftp.gtk.org.
   ***
   *** If you have already installed a sufficiently new version, this error
   *** probably means that the wrong copy of the gtk-config shell script is
   *** being found. The easiest way to fix this is to remove the old version
   *** of GTK+, but you can also set the GTK_CONFIG environment to point to the
   *** correct copy of gtk-config. (In this case, you will have to
   *** modify your LD_LIBRARY_PATH enviroment variable, or edit /etc/ld.so.conf
   *** so that the correct libraries are found at run-time))
   no

Does it *really* need 1.0.6 and not 1.0.4?  Has it changed *that*
much?  It's just a 2 version minor release difference!  It was also
somewhat confusing because the above complaint came in and scrolled
off the screen, leaving what looked like a successful configuration,
but compilation failed from screwed up makefiles.

In any case, I tried to satisfy its hunger by upgrading GTk - doing a
cvs update & rebuilding.  This one failed when running autogen.sh:

   aclocal: configure.in: 174: macro `AM_PATH_GLIB' not found in library
   configure.in:150: warning: AC_TRY_RUN called without default to allow cross compiling
   configure.in:151: warning: AC_TRY_RUN called without default to allow cross compiling
   configure.in:392: warning: AC_TRY_RUN called without default to allow cross compiling
   configure.in:410: warning: AC_TRY_RUN called without default to allow cross compiling
   configure.in: 508: required file `gtk/gtkfeatures.h.in' not found
   configure.in:150: warning: AC_TRY_RUN called without default to allow cross compiling
   configure.in:151: warning: AC_TRY_RUN called without default to allow cross compiling
   configure.in:392: warning: AC_TRY_RUN called without default to allow cross compiling
   configure.in:410: warning: AC_TRY_RUN called without default to allow cross compiling
   creating cache ./config.cache
   ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE($PACKAGE,'
   ./configure: ./configure: line 581: `AM_INIT_AUTOMAKE($PACKAGE, $VERSION, no-define)'

   Now type 'make' to compile Gtk+.

The last line is especially funny.  Make yields:

   hjstein@bacall:~/software/gimp/gtk+$ make
   make: *** No targets specified and no makefile found.  Stop.

Checking the docs (HACKING), I discovered that I have the right
version of autoconf & automake, but not libtool.  I only have version
1.2, but GTK+ wants 1.2b!  I guess they must have really needed some
new feature from the latest bleeding edge release of libtool to make
things work.  Couldn't possibly live without it, or detect the
difference and work around it, or ...

Next, I'm sure I'll find it doesn't like my version of guile.

Not that I'm against all this rapid development, but it does make it
more difficult for people trying to keep up.  And it just keeps going
on & on - I don't like installing things on my system without RPM
wrapping them, I'm still running RH 4.2, and I still have lots
of *old* pre-redhat binaries floating around.  The thought of having
to recompile all these old things (and things which I stuck in without
RPMing) keeps me from upgrading to 5.2.  So, additionally I can't get
the latest releases from redhat or from people who've packaged binary
RPMs because they're usually for >= RH5.0.  And, I often can't even
build the source RPMs because they depend on newer version of rpm
which I can't build because...

So I'm left repackaging RPMs myself, hacking spec files, and upgrading
huge chains of dependencies..

Again, I don't *really* want to whine & complain about this.  It's
*good* that software is being developed.  I just want to point out
that it's not just the new auto* & libtool stuff layered on top of
autoconf that's a problem.  I think it's more that the version
interdependencies are getting a little ridiculous and difficult to
keep up with.

I also don't want to single out guile, scwm & GTK+ in particular.  I
ran into a similar upgrade frenzy trying to upgrade the Gimp, as well
as a few other packages.  It's getting to be quite endemic in the free
software arena now that more people are getting in on free
development and packages are getting more & more complex and
interdependent.

Maybe all it would take is a little discipline on the part of the
developers to make do with older components.  I'd think that would
make a big difference for the larger circle of people who are trying
to help out.

--
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il