Re: [Boost-build] bjam 4.0.. in C++

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Spencer E. Olson (olsonse_at_[hidden])
Date: 2010-05-27 13:07:03

All,

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 
time being.  

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 
board.  

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?

Just concerned,

Spencer

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.