| |
| |
| $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. |
| |
