Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Spencer E. Olson (olsonse_at_[hidden])
Date: 2010-05-27 13:07:03
I'd like to hear feedback with regards to the future of Boost.Build/bjam. A
colleage recently attended BoostCon and came back with the impression that
Boost.Build would be replaced by Kitware's CMake for Boost's primary build
system. Apparently, someone asked "who uses Boost.Build in non-Boost
programming" and very few people raised their hands. On the other hand,
after the question "who uses cmake in non-Boost packages" and several people
raised their hand.
I work with a group that uses CMake for our primary software development. I
have been using Boost.Build/bjam for other projects. During development, I
can't stand to use CMake and BBv2 really helps me get things done easier and
quicker. When we decided to move to CMake (from straight Makefiles), we
examined several build systems: BBv2, CMake, SCons, ... Although using BBv2
would solve many problems faster, we determined that CMake would do a better
job for the long run because of 1) maintainability (other developers would be
more willing to learn the CMake language), 2) configuration detection, 3)
ability to modify configuration, and 4) errors at CMake time can be
understandable. (I might add that we were excited to try SCons since an all
python system would have the potential to provide an easy and extensible
language--we were unfortunately very dissapointed--they have many design
flaws that I don't want to go into here.)
The runner up was BBv2. The primary negative marks on BBv2 were 1) the odd
and picky language (why does the semi colon really to be white space
separated--please don't answer this) and 2) the error messages are not very
intelligible--it takes a bit of practice to parse out the meaningful
information from the several lines of less useful information.
Personally, I feel that the behemoth CMake is first a behemoth (gigantic),
difficult to install on complex platforms, painful to work with, frought with
bugs, lacking in a responsive developer community (just try and get the
primary developers to help you fix CMake bugs if you don't have a contract
with them and you don't promise them something great), and does not increase
my productivity as a developer, but rather decreases it. There are now
several developers that I work with (actually all of us I believe) that think
CMake is just an abomination, but an abomination we are stuck with for the
BBv2 on the other hand is small, easy to move around and install on complex
platforms, and has really enhanced my productivity as a developer. I find
that with BBv2, I spend very little time massaging the build system and most
of my time doing actual development. If only the language were easier and
extensible, then having it detect and tweak configuration on complex
platforms would be possible. Furthermore, I could get other developers on
But, alas. The best technology and ideas do not alway win out. Think VHS vs.
Betamax, Microsoft vs. everything else, and so on. As I view it, if Boost
were to drop BBv2 as the primary build system, its future would look pretty
bleak. I understand that Kitware is really pushing hard to get Boost to move
to CMake and several others have jumped on the CMake bandwagon. So, my
question to this group is: where is Boost.Build going? Is the battle
against CMake a lost cause? Are you all thinking of how we might change this
situation? Are we doing anything to spread the developer base of Boost.Build
so that it can live without Volodya?
On Saturday 22 May 2010 07:57, Rene Rivera wrote:
> Once upon a time I started thinking, investigating, sketching, and doing
> some minor coding for a rewrite of bjam in C++ to address the various
> problems. Mainly the horrible memory management and hence speed.
> Unfortunately at the time I had decided that it would not depend on
> Bosot libraries in the hope of preventing a rather nasty boot-strapping
> problem. This presented problems as I couldn't find any good
> lexer/parser that played nice with C++ and wasn't a big PITA to use. It
> also loomed on my how much of Boost I would end up writing anyway. So
> I've just about decided to abandon my assertion that a new bjam would
> not depend on Boost. But I thought I would ask for feedback on this
> before continuing down this path. The new plan would be to:
> * Have bjam 4 depend on a *released* version of Boost.
> * Written with Spirit as the base lexer/parser.
> * Have a variety of syntax improvements and support for UTF8/Unicode.
> I'm cleaning up the branch where I started this work at the moment. But
> I'd like to hear ideas and comments on the new approach. And if you have
> feature request for such a rewrite now would be a good time to voice
> them, so we can add them to trac.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk