Boost logo

Boost-Build :

From: Michael Caisse (boost_at_[hidden])
Date: 2007-05-17 14:52:00

Dean Michael Berris wrote:


> Now that the intention is clear that you don't want any part of the
> "let's fix it [documentation]" effort, I guess that leaves just
> Vladimir Prus and I -- and maybe other people who haven't sounded off
As you can probably tell from my previous posts... I'm keenly interested.
I've been pouring through bjam code and jam files for the past week trying
to get a handle on the system. I'm not interested in a make generator. I
have enough problems with nmake and the sort... I have much better luck with
bjam (BBv2) so far. I think a user manual (I've been toying with an O'Reilly
style guide/book) is required. Most people I know (except for those clever
librarians) write "make" files by looking at examples of what they have
done in the past. So a clear guide on what the grammar/language is followed
with lots of examples might be a great start.

<more snip>

> The "bjam being slow and resource hungry" problem might be addressable
> somehow -- how I don't know yet, but I'm guessing it might require
> doing major surgery on the jam codebase (which is in C). It might also
> involve having to use Boost.Graph for the dependency tracking,
> Boost.Spirit for parsing the Jamfiles, Boost.Filesystem to work on the
> files, and maybe Boost.Python to expose these lower level
> services/components to a Python engine which drives the build process
> (using the external tools like compilers, linkers, assemblers,
> whatnot). I don't know if the above makes sense or whether it's
> feasible but leaving the jam legacy code might be a step in the right
> direction.
My first impression is that bjam has diverged enough from jam that this
might make a lot of sense. Keeping similar code bases is helpful if there
is some synergy that can be gained (shared bug fixes). I've been looking
at the code and thinking about a C++ port that simply uses the standard
library. This has initial appeal to me because it would not require the
enormous boost package to build; however, I'm not sure it is worth loosing
the boost library benefits.


> So if Boost does decide to use CMake as *the* build system of choice,
> I still don't see why Boost.Build would have to disappear into the
> sunset when people actually use it.
It wont. There has been a good response from an existing user base. I don't
mean to sound so negative about CMake, I'm sure it is a fine makefile generator....
but I'm trying to get rid of the other make/nmake/vcproject/gmake systems from
my builds.

Best Regards -

Michael Caisse
Object Modeling Designs

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at