Subject: Re: [Boost-build] Son of b2 - suggestions
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-02 07:53:43
Am 02.11.2016 um 12:27 schrieb Paul A. Bristow:
>> -----Original Message-----
>> From: Steven Watanabe [mailto:watanabesj_at_[hidden]]
>> Sent: 31 October 2016 16:41
>> To: Boost.Build developer's and user's list
>> Subject: Re: [Boost-build] Son of b2 - suggestions
>> 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:
> Well that's good for the language writer and keen user, but I feel that the main problem for most users is that bjam syntax is just
> not *intuitive*. (Some aspects like the use of layout as keywords is positively counter-intuitive and trips up most users - Paul
> Dirac might have said it was "Not even Daft").
Well the actual jam-syntax is, but the complex rules etc boost.build
puts on top of that make it weird.
> Now you will probably ask why *this language* needs to be intuitive. Well I think that it is because most users are not really
> going to write in it, they are just going to read it to understand what is happening, and perhaps tweak a little. And they only get
> to tangle with it when things are already dysfunctional. The last thing they want is yet another ***** language.
> If you main users are doing C-ish stuff (and that includes C++, Java, .net .. Python and FORTRAN even) then it should *look like* a
> C-ish procedural language, even if it isn't. It should minimise what you need to 'Just Know', or RTFM to find out.
I think that's wrong, because your language does not do procedural
stuff. That's actually what confused me about jam, that you have rules
which look like target declarations but are mere functions, e.g. glob. I
think the jam-syntax is nice for what it is supposed to provide: a
language for declarations.
For example "main = exe(glob(src/*.cpp));" would be confusing, because
with that syntax you would expect exe to already build and then return
the file name, not that it declares a target.
It should look like a target declaration, e.g. like in make, because
that is what it is. Now function calls should look like function-calls,
so I would be for something like that "exe main : glob(src/*.cpp) ;".
> 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