Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Fabien Chêne (fabien.chene_at_[hidden])
Date: 2010-06-02 04:34:49
2010/5/22 Rene Rivera <grafikrobot_at_[hidden]>:
> 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.
I'll be glad to see speed improvements in BBV2. From my experience, In
my company, we've never been stucked with BBV2, but as projects grows,
it becomes slightly slower and productivity decreases. This is the
major drawback for us -- documentation is certainly not perfect, but
for me, it is not so bad. The other thing we don't like is the
approximate parsing of #include directives -- which is worth
documenting. I mean:
Here foo.h will be unconditionnaly tracked as a dependency.
More importantly, the following exemple will ignore the dependency,
which may results in miscompilations:
#define BAR bar.h
If it is admitted that you can reuse boost libraries, what about using
Boost.Wave to tackle this problem ?
Also, note that I have a patch for GCC to diagnose the problem above:
it adds a new option -Wdependent-includes, and diagnose the BAR
missing dependency. Are BBV2 users interested ? (I know that Boost
people won't be interested because the BAR trick is used inside to
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