$Id$

This is an agglomeration of notes about using autoconf and friends to create
the build environment (configure script, etc) that builds and installs
Rivet.  It will probably go away eventually.

WHERE IS THE CONFIGURE SCRIPT?

If you've checked out the source tree from CVS, you'll notice there's no
configure script, and no configure.in, and no Makefile.in, etc.

You get to fiddle the autoconf stuff to create all that.

VERSIONS

autoconf and stuff has evolved, and old versions won't work and will cause
weird problems.

autoconf 2.59
automake 1.9
aclocal 1.9
autoheader 2.59

BUILDING IT

First you gotta run "aclocal" to create the aclocal.m4 file.

Then you can run "automake" to create the Makefile.in files from
the Makefile.am automake source files.  NOTE that even though automake
runs autoconf, you still have to run autoconf.

Run "autoconf", make sure you're getting the right version by doing
autoconf --version

Run "autoheader" to generate the config.h.in

Once all that is complete, you can probably run configure.


AUTOMAKE

Automake greatly simplifies the complexity of the Makefiles.  With automake
we generate Makefile.am.  Automake will create the Makefile.in, which
configure, as always, will use to generate the Makefile.

Automake could be brought to TEA extensions to greatly simplify the
complexity of their build definitions (configure macros, Makefiles, etc)

LIBTOOL

libtool super simplifies and standardizes building shared and static 
libraries across tons of variants in operating system architecture
around shared libraries, linking, etc.

A libtool script is generated by running the configure script.  The libtool
docs suggest shipping libtool.m4 in your package, else there's no guarantee
aclocal, etc, are going to be able to find one on the local system that
will work, should autoconf need to be run, etc.

A recurring maintenance task for the Rivet team will be to freshen the
libtool.m4.

Libtool also offers substantial simplification to Tcl extension writers
and maintainers.

TCL.M4

There's a bunch of stuff Tcl extensions (and Tcl, etc) need to know about
systems and it's all set up to be handled by tcl.m4.

We've hacked on tcl.m4 from the Tcl Extension Architecture (TEA 3.1)
version.  Our changes should probably be folded back in.

VERSIONS AND ENV VARS

It appears that the autoconf tools are moving towards versions, where
aclocal 1.9 can be run as aclocal-1.9.  This is good.

FreeBSD ports, though, had already been doing this, so there this stuff
is called, for instance, aclocal19.

You might need to set up environment variables to tell the autoconf tools
the names autoheader, autoconf, automake, and aclocal are installed under,
something like this:

export AUTOHEADER=autoheader259
export AUTOCONF=autoconf259
export AUTOMAKE=automake19
export ACLOCAL=aclocal19


CONFIG.GUESS AND FRIENDS

Ever wonder where config.guess, install-sh, and stuff come from?
(You see them in a lot of packages.)

This stuff a lot can get pooped out there using libtoolize.

libtoolize --force --copy to install config.guess, config.sub, ltmain.sh

This stuff is in the tclconfig directory, which isn't really the best
name because it's grown to include a lot of autoconf-related stuff.