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

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2010-05-24 16:56:23

Hi Spencer,

On May 24, 2010, at 9:15 AM, Spencer E. Olson wrote:

> I've heard that one of the Sandia projects that was attempting to use
> Boost.Build did suffer from speed issues with bjam.

Ah yes, the grapevine...

Speed issues... a long subject.  When we replaced our in-house  
developed tools with Boost.Build, we found the build speed /  
throughput to be the same as the limited capability in-house tools we  
were replacing.  Once we had a functioning minimal (Boost) build  
system we went on to move all of our source code, including third  
party libraries we depend on, into Boost.Build, and here we noticed a  
considerable slowdown.  Because we'd never had the ability to use a  
single build system to build our entire (developed and dependent) code  
base from source, the slowdown didn't concern me too much and it  
wasn't an impediment for our external customers.  Some of our internal  
developers, on the other hand, were quite bothered by it so they went  
on to wrap the Boost build system in a Make layer (called Bake).  Bake  
would run bjam, capture the build commands, write them to a makefile  
and then Bake would just invoke make on this makefile.

Our key performance problem with Boost.Build was recomputing the  
dependencies from scratch each time the user ran bjam so the Bake  
layer amortized this cost (run bake 50 times, then rerun bjam to bring  
dependencies up to date) at the expense of firmly pushing the  
dependency tracking obligation onto the users.  Because most  
developers work inside a single library where the include and library  
dependencies don't change that often, this tradeoff was considered  
acceptable.  Our developers also have significant problems grokking  
the Jamfile syntax but a handful of them have learned how to modify  
the Jamfiles and interpret the error messages.  Jamfile changes are  
rather less common now that the system has been in production and  
stable for a few years.  Given the complexity of what we do,  
Boost.Build delivered a product that, with significant customization,  
has virtually eliminated the build system as an impediment to either  
our external customer or internal developer productivity.  That's a  
pretty significant accomplishment IMO.

-- Noel