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

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Gevorg Voskanyan (v_gevorg_at_[hidden])
Date: 2010-05-22 13:17:33

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.

I can imagine released Boost version is important here because otherwise a problem in a dependent library in trunk can break all tests of all libraries in trunk. This does not exclude the possibility of bjam sources in a released boost package to depend on boost libraries from the same package, and successfully build without requiring any external boost headers/binaries. In fact I consider that a pretty fundamental requirement. As long as bjam depends only on header-only boost libraries this should not be a problem, right?

>  * Written with Spirit as the base lexer/parser.

Sounds good. Will make the task a lot easier I think.

>  * Have a variety of syntax improvements

Such as being less demanding for whitespace? Anything else you are thinking of?

> and support for UTF8/Unicode.

Could you please elaborate on where/why this is needed? Path names?

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

Recently I had a case where a "class" was being defined twice due to environment misconfiguration (a class with the same name was being defined in two different modules), to which bjam responded by abort()-ing itself :)
Cleanly exiting would be more preferable, as would indicating which 2 modules were to blame for redefinition, IMO. Clean exit would be easier to achieve with C++ rewrite by just throwing an exception in such a case. Not a (major) feature request actually, but that's what immediately came to my mind. I'll keep thinking more about possible feature requests in the coming days and report them if there are any.

Thanks,
Gevorg