Jamming

[Lex Spoon]

I've worked with Jam a good deal at this point, and it is my favored
build tool when I start new projects.  If anyone tries to use it with
Squeak, here are a few thoughts from my experience.

First, a good autoconf strategy is for autoconf to create a single file
"Jamsettings"  which holds most of the build options.  This file is
simple and easily hand-hackable; this is nice, because then I can
manually maintain make a Jamsettings.win32 and Jamsettings.osx for
platforms which are different from normal Unix boxes and which autoconf
doesn't work well.  Also, if autoconf ever guesses wrong (and come on,
it sometimes does), users are not up the creek -- they can hack a single
file and then move on.

With this approach, conditional build options show up as conditional
statements in the Jamfile.  Remember that you can write things in Jam
such as:

	if $x11_libraries_present {
		include plugins/vm-display-X11/Jamfile ;
	}

and:

	if $awk_present {
		interpc = "gnu-interp.c" ;
		Gnuify gnu-interp.c : interp.c ;
	} else {
		interpc = "interp.c" ;
	}

This is extremely useful, and means that you should not need to have
complicated scripts in your autoconf setup--instead, the conditional
stuff is in the Jamfile, which is a nicer language that Bourne shell. 
It also means autoconf goes back to its main job of checking for what is
on the system; it does not get involved with patching together makefile
fragments or anything like that.

A second thing to think about, is to divide your jam code into a library
part and a users part.  As with any library, it is worth spending
significant time up front to design a nice interface.  For example,
maybe you want plugin Jamfiles to look like this:

	PluginFile "FooPlugin" ;

	PluginCFile foo.c ;
	PluginCFile bar.c ;

	EndPluginFile ;

Or maybe you want this:

	Plugin FooPlugin : foo.c bar.c ;

Think carefully about it, and skim through the individual plugins to see
what is possible.  As one tip here, don't get carried away and try to
make too many things automatic.  I find it a good a general rule of
thumb to name each source file exactly one time.  More than this is
okay, but less than this is often a false economy.  The Jamfiles may get
shorter, but they become so much more complicated that it isn't worth
the savings.


Once you have your interface worked out, you can then make a Jambase
which defines subroutines like "Plugin" and "PluginCFile".  These will
expand to smaller rules, and eventually to "actions" which set up the
low-level dependencies and give the specific build rules.

Finally, you might want to ignore Jam's much-vaunted "grist", and
instead use full pathnames.  Grist, IMHO, makes the Jamfiles shorter,
but it's another false economy.  Grist is a significant time investment
to learn from the existing documentation, and it's fiddly (some rules
use it, some don't) even once you understand what is going on.  Maybe a
very clever guy can overcome these hurdles; I just want to toss out that
some people have gone there and have not found it worth the hype.

Good luck, anyone who goes for it.  I expect, as with Squeak, you will
get addicted... and then want even more.

Lex