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 :-)
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