Jamming

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: Jamming

Giovanni Giorgi-4

--- Lex Spoon <[hidden email]> wrote:
> 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.
Where can I find more information on Jam? it looks very very interesting

// Giovanni Giorgi    http://www.siforge.org

Reply | Threaded
Open this post in threaded view
|

Re: Jamming

tblanchard
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oh please, no.  That will just create yet another thing to download
before building a vm.

make is fine, make is simple, make is ubiquitous, make is already there.

Ian's build works.  It works remarkably well.  Ian is very responsive
when it doesn't work.  Ian does very useful things for the unix/squeak
community and therefore Ian should use whatever makes Ian happy.

On Apr 9, 2005, at 1:57 AM, Giovanni Giorgi wrote:

>
> --- Lex Spoon <[hidden email]> wrote:
>> 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.
> Where can I find more information on Jam? it looks very very
> interesting
>
> // Giovanni Giorgi    http://www.siforge.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCW0THhullemWJdQ8RAkziAKCt041eI7YCr0Sty0C61XHplKitDwCfb+73
oLsYlIfCcpvMjpwA98caGwk=
=VUyz
-----END PGP SIGNATURE-----