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 14:59:55

Rene Rivera wrote:
> 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 point :-)

Yeah, my main concern about compiled libs here is that a separate list of source files of a library needs to be created (in parallel with the list in the library's jamfile), and updated as appropriate when the library's jamfile changes. And we can't just use [ glob libs/xlib/src/*.cpp ] as we could in a jamfile. And possibly need to modify the list based on BOOST_VERSION somehow, to keep bjam sources backward compatible with older Boost versions. Just too much a pain managing all this :-)

>> Such as being less demanding for whitespace?
> 
> Yes, although that will be a tricky one if we want to keep backwards compatibility.

I imagine ambiguity related to conditional requirements could be a problem for example? We could perhaps allow to omit whitespace only at certain points in syntax. But that would probably ruin the possibility of using a lexer at all, and hence would require it all handled in syntax specifications, complicating grammars noticeably. This would be clearer to reason about if we have a comprehensive list of backwards compatibility issues that'll arise, though. Needless to say I am all for keeping backwards compatibility, to the extent possible :)

>> Anything else you are
>> thinking of?
> 
> * Possibly allowing for non-shell embedded actions. For example writing actions in Python, Lua, and other interpreted languages.

That's a good one, makes writing portable actions easier.

> * Better support for string escapes.
> 
> * Built-in types other than strings, i.e. numbers.
> 
> * Built-in arrays, maps, sets.

These are good enhancements, too; from performance point of view as well.

>>> 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 didn't know that was not already the case... Then, it's a must-have. At the very least all paths should be stored in utf8. I'm not so sure about all other strings though, but having them in utf8 too would probably not hurt either.

>> to which bjam responded by abort()-ing itself
> I'll file that under better error reporting and handling :-)

Thanks :)

Best Regards,
Gevorg