----- Original Message ----- From: "Brett Calcott" <bret...@paradise.net.nz>

An excellent choice, if I do say so myself ;-)

Thanks.

I have corresponded with Christopher Seiwald, the Jam maintainer, about making changes to the underlying Jam (C/C++) source code. He seemed generally receptive to a collaboration on a few modifications. I have not asked him about folding new Jamrules into the Jambase. I am guessing it would be a hard sell, however. He (and others I suppose) have an investment in projects built around the existing Jambase. My stuff adds a lot of code to that, with capabilities and complexity that these existing projects apparently don't need. I have made some effort to keep the functionality of existing Jambase rules available in my work, but there's no guarantee that everything works exactly as it used to.

Yes, in fact, I am beginning to find that to get certain things right the freetype-specific "subst" rule (http://freetype.sourceforge.net/jam/index.html#diff) may be neccessary. Jam's built-in string/path manipulation facilities are pretty weak, and can only get you so far, unfortunately.

Two things:

1. allyourbase.jam is a modified Jambase; I needed to replace some of the Jambase rules, including SubDir, which gets called before Jamrules is read.

2. I still think it is useful for a project to have a Jamrules file which starts as a blank slate. I didn't want project users to have to muck about in allyourbase.jam just to add a few rules or variable definitions of their own.

Of course, the system is under development. Having all those files floating around is obviously a bit inconvenient. When things get more stable, I think it would make sense to compile allyourbase.jam and boost-base.jam into Jam as a new Jambase. For now, I thought it would be useful if people using an out-of-the-box Jam could try out the build system.