[jamming] Announcing XJam 2.5

[Alen Ladavac]

Hi Craig, Richard, and all the list in fact,

This reminds me of a thing that I've been kind of thinking about "in
the background" for quite a while, and I'm more and more sure that my
theory makes sense...

I believe that the limiting factor dictating the fact that Jam has not
evolved much further after 2.5 and that it has not flourished and
(ta-da...) overtaken the world of build systems, is the fact that
there is a too strong cohesion between the jam executable and the
jambase/jamrules fileset.

Why? Here is my train of thought on this:

#1 People use jam primarily because they want to be portable and/or
support a large number of different output configurations and/or
compilers. Otherwise they'd use the default build system for their
one main target (.vcproj, Makefile, ...).

#2 Jambase is embedded in the jam executable to simplify building
small projects - in a large project you wouldn't really mind popping
in one or more additional files to define the overall build rules.

#3 For large projects, stock jambase cannot satisfy different
individual needs for each project, so people keep coming up with their
additions or rewrites.

#4 Some or most of those changes in #3 require at least some
extra feature in the jam executable's functionality.

#5 But the extra features in #4 cannot be used without modifying
jambase. (It is not like you cannot build the exe without that, but
some kind of developer etiquette would mandate that you have an
interface for your feature, and right now jam together with jambase is
considered "the product".)

#6 As people doing large projects (who do #4, because they need #3)
have their own jambase/jamrules filesets, they don't have time and
energy to update jambase as #5 would kind-of "morally require".

#7 Replacing the stock jambase with a customized version does not
facilitate collaboration in creation of new improved jam version,
because come of those changes dig in too deep in the system or are
mutually exclusive. Which is why there are several branches of jam,
mostly ending up in dead ends.

What I would propose is that jam be parted from jambase, so that one
main line of jam can evolve separately from zillions of different
jambase/jamrules filesets. This would make submitting and building
patches that add new functionality to the jam exe much easier. The
various jambases can then be maintained as separate projects which
would be much easier to evolve more quickly (completely portable and
no recompile required), and can have their own lifecycles of various
lenghts and die off if they are uninteresting.

I know that maybe a glaring issue is the fact that main jam doesn't
really have an active maintainer atm. But even if it did, it would be
much easier for people to submit new patches and for the maintainer to
take care about the project if jambase was separated. And I think that
this may be one of the reasons why there is no maintainer - doing so
is too complicated for the reasons above.

Sorry for the long rant and let me know what you people think.

Cheers,
Alen



Craig wrote:

> Hi Richard,

> Yes you could, but a couple of reasons why we don't do that...

> 1. For those people building on one singe/dual/quad core machine
> perhaps that is fine. But when you use a larger number of jobs, say
> -j15 or more there will be a stall of jobs between your jam
> invocations. However, if you do them all at the same time jam can be
> compiling the next executable's source whilst it is linking the
> previous one. Add to that, you may want to build debug, release and
> retail of 3 platforms too...

> In this case you'd want to "UseModule" on more than one platform at
> the same time. Stock jam requires very little changes to facilitate
> this. You just need to set the approprate variables for each variant
> before calling Main. So how I do this is by another Main (this is a
> simplified version to demonstrate the point):

> rule Main2
> {
>   PLATFORMS = pc ps3 ps3spu xbox ;
>   TYPES = debug release retail ;
>   for p in $(PLATFORMS)
>   {
>      for t in $(TYPES)
>      {
>         # set appropriate variables for this combination here
>         Main $(<) : $(>) ;
>      }
>   }
> }

> Of course you need a method of determining which variant you're
> building. You could use grist but we choose instead a simple suffix
> that includes platform and type, e.g. _xd might mean xbox debug. So I
> can build my variants specifically like so:

> jam Game_xr Game_xd Game_xf Game_pr Game_pd Game_pf Game_r Game_d Game_f

> Of course a sane person would have made some handy pseudo targets.

> 2. You might want to embed some data that you build on your host (e.g.
> pc) into your target executable (e.g. playstation). You could run jam
> to build the data, then run it again to build the executable. Why not
> do both, I mean perhaps all you want to do is say:

> jam Game_playstation_debug

> And the executable is dependent on the embedded data so jam will build
> the pc tool with vc compiler/tools, that builds the data, that
> generates a .c, that is compiled using gcc into .o, that is linked to
> your target executable.

> Just food for thought.

> Craig.

> ps. By the way, there was a post not long ago to fix a problem whereby
> if you pass several targets on the command line stock jam will treat
> them as if you did call jam each time.


> On Mon, Jun 16, 2008 at 11:11 AM, Richard Mitton <mitton at treyarch.com> wrote:
>> Well I guess you'd just call jam 4 times with a different parameter, and
>> just include the appropriate module each time.
> _______________________________________________
> jamming mailing list  -  jamming at perforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming



-- 
Alen