Re: [Boost-build] Son of b2 - suggestions

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:
> AMDG
>
> 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:
> http://www.boost.org/build/doc/html/jam/language.html

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

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
>