Subject: Re: [Boost-build] Son of b2 - suggestions
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-10-31 16:06:32
On 10/31/16 9:40 AM, Steven Watanabe wrote:
> On 10/31/2016 10:18 AM, Robert Ramey wrote:
>> On 10/31/16 5:05 AM, Klemens Morgenstern wrote:
>>> Imho b2 failed because the documentation is not nearly detailed enough,
>>> the language is strange and building extensions is painful. Not as
>>> painful as using CMake, that's why I'm doing it, but it still feels like
>>> masochism. The real limit of b2 is constituted by it still using jam,
>>> and all other (except for the documentation) come from that.
>> Oh - no problem - just enhance the documentation and problem solved.
>> Of course this is not going to do it. The problem is what if one writes
>> a program which requires pages and pages of arcane documentation to
>> describe it, you've done something wrong and need to step back an see
>> what it is. That "something wrong" is usually that the "language" has
>> no rime or reason - it's a grab bag of features each with it's own
>> syntax, which are coupled together in unexpected ways.
> The Jam language itself is actually extremely simple.
> The complete yacc grammar is less than 200 lines
> of code. (337 lines including all whitespace,
> comments, and scaffolding.) The documentation
> here is pretty complete as well:
When I used the word "language" I wasn't referring to the Jam language
python or anything similar. I've been trying to make the point that
this is an implementation issue and it's premature to address it in this
I'm really referring to the the ideas which the build systems describes
and builds upon. In this context b2 (to my limited understanding) has
"targets", "features", and ??? as well as ways that these are composed.
This is analogous to the arithmetic where we have integers and +, -, etc
which compose and transform them. Similarly in accounting we have
debits, credits etc and we have ways of operating on them to produce
other artifacts such as balance sheets, income statements etc. The fact
that these systems can implemented in C++ not no relevant to
understanding and evaluating them independently of the implementation
method - which is what I propose be done.
This is a main theme behind my recent presentation at CPPCon C++,
Abstract Algebra and Applications.
> In Christ,
> Steven Watanabe
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
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