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

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2010-05-27 13:58:53

On 5/27/10 1:07 PM, in article 201005271107.04024.olsonse_at_[hidden],
"Spencer E. Olson" wrote:

> 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.
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
> 
Funny, I use CMake all the time and don't have the problems you are
describing. Different strokes for different folks. I don't want to debate
CMake versus bjam ( at least on list...), it has been done all over the
place on the internet.
  With that stated, I was excited (and helped in a small way) to try and
move Boost to CMake as a build system. Funny thing in the process I got a
hard lesson about open source software. Don't mess with an entrenched
developer community. They don't want to move. Do I think Boost will ever
move to CMake? Probably not. Just too many people to try and get the
momentum moving in another direction. I think CMake brings some pretty cool
tools to the party (CPack for creating installers, CTest for easy unit test
reporting) that would enhance further the quality of releases.
   So while there is talk of moving boost to CMake, it is just that: Talk.
There is NO momentum behind the move from what I can tell. The Boost-Cmake
project is languishing at version 1.41.0. The primary developer(s) behind
the Boost-Cmake project are updating anything anymore and I don't think
anyone else knows how to step forward to help coordinate a release.
 So in the short term I wouldn't think you have anything to worry about
with CMake replacing BJam in Boost.

Mike Jackson
Www.bluequartz.net