Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-05-22 13:57:18
On 5/22/2010 12:17 PM, Gevorg Voskanyan wrote:
> 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?
Right, depending on the current release if packaged with it should be
fine. Not sure if we'll be able to stick to header-only libs though.
Although it would be my goal to do so just to reduced set up problems.
But even if we do end up using compiled-libs they would be directly
statically compiled in anyway as using the BBv2 build files for the
would be out of the question. Just too many bootstrap problems at that
>> * 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?
Yes, although that will be a tricky one if we want to keep backwards
> Anything else you are
> thinking of?
* Possibly allowing for non-shell embedded actions. For example writing
actions in Python, Lua, and other interpreted languages.
* Better support for string escapes.
* Built-in types other than strings, i.e. numbers.
* Built-in arrays, maps, sets.
>> and support for UTF8/Unicode.
> Could you please elaborate on where/why this is needed? Path names?
Paths would be the minimum.. Another is having things like Unicode regex
support for header scanning since it's now not uncommon to find Unicode
source files. But both of these essentially boil down to having all
strings in bjam be unicode/wide/utf8.
>> 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.
I'll file that under better error reporting and handling :-)
-- -- 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
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