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

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-05-24 12:15:52

To everyone saying the docs need work. Yes we know ;-) And as everyone 
knows it's hard and long work to improve them. I don't have the time, it 
would take me al of today to respond to each of the post about it. So 
consider this a +1 from me also on the whole documentation topic.

On 5/24/2010 10:43 AM, Anthony Foglia wrote:
> Would a faster boost-build help? Of course, but there are probably hacks
> that can be done to speed things up short of a rewrite. (For instance,
> it looks like boost-build spends a lot of time parsing system and third
> party headers. Why can't boost-build store a parsed dependency tree for
> everything outside of the Jamroot, and rely on that? For concerns about
> not having a clean build, have it turned on with a command-line
> parameter. It's clumsy, but it should work 90% of the time.)

I am considering all caching options possible in the new version. I 
should mention that doing that in the current state is a horrible pain. 
But I do have one question..

Everyone keeps saying that the header and dependency scanning is taking 
up a bulk, or a lot, of the time. But all the performance tests I've run 
never show that. Instead they show that the large memory use consequent 
of the way strings and variables are handled by bjam are the main 
performance problem. So.. Have I misdiagnosed this performance problem? 
Do people have measurements I should be looking at that show the 
dependency scanning problem?

> The best way to get more people to use it, is to make it easy to use in
> the common cases.

OK. I think that summarizes the whole documentation and consistency 
argument. Perhaps you can start a different thread as to how to make 
Boost Build easy to use. We really do want to know specific ideas on this.

> I'm sorry if this comes off as harsh.

People should stop apologizing for harshness.. I'm one of the first ones 
to bash my own tools :-) Yes, bjam/BB has *many* rough edges and 
outright problems. And I see them regularly because I myself started 
out, and still I'm, a bjam/BB user. (Long ago now)

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail