|
Boost-Build : |
Subject: Re: [Boost-build] Son of b2 - suggestions
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-11-15 16:43:30
On 15.11.2016 16:18, Robert Ramey wrote:
> On 11/15/16 12:18 AM, Vladimir Prus wrote:
>>
>> Hi Paul,
>>
>> On 29-Oct-16 2:57 PM, Paul A. Bristow wrote:
>>> A few suggestions as you are getting closer to prototyping.
>>
>> Thanks for this list! I think the points you made are pretty good, and
>> many are good points for all domains; I have even printed out this email
>> for future reference.
>>
>> There are a few points (some implicit) on which I don't quite agree, and
>> I wanted to spell it out.
>>
>> - As far as I'm concerned, we're not looking for a full-blown
>> from-scratch rewrite. Getting where we are took some time and effort,
>> and redoing everything is unlikely to work. There, I do agree with
>> http://www.joelonsoftware.com/articles/fog0000000069.html
>
> a very good reference.
It's an interesting (often cited) article indeed. Still I think it's a
bit simplistic. Code is being rewritten all the time, though mostly at
much finer granularity than at the level of an entire project. The
importance is not so much at what granularity level code is being
rewritten, but whether there is still some form of continuity, at least
at the conceptual level, whether all that knowledge that has evolved and
was materialized in the code will be preserved, and will inform the
development of the next generation of the code.
The scenario Joel alludes to, where programmers start over because they
think the original code is "a mess" is a caricature, with some grain(s)
of salt (as is the case with all good caricatures). And - if I may
rephrase Vladimir's suggestion - the main point needs to be to be aware
of the knowledge encoded within b2 when suggesting future directions.
> I've worked with both CMake and Boost Build for many years so I'm more
> familiar than I want to be with these systems. In my view, Boost
> Build has very good functionality. Once one has things set up, I've
> found it to be very reliable. Of course everyone knows that my
> complain has been that's it's very hard to get setup. I've never
> thought that the problem with it was the code itself, the language
> it's coded in (jam). I think the problem is the same as many, many
> software projects - a few guys write the code then the rope someone
> into documenting it. At that point it becomes clear that conceptually
> its ambiguous. Of course the original programmers don't see this
> since it always made sense to them.
> (I know I constantly rant on this - sorry).
Indeed, being able to pass on the accumulated knowledge that led to a
given code requires thorough documentation at different levels.
>>
>> - Both you and Robert bring 'too clever' point. While I understand
>> this sentiment, being 'clever' is design goal of Boost.Build.
>
> Ahhhh - clever in itself isn't really the problem. To me that's an
> implementation issue. The problem is lack of "conceptual integrity"
> and conceptual "layering". This would permit one to understand it
> using simpler concepts which can be either composed and/or layered.
Amen ! That's exactly where I'm at right now in my trying to grasp b2 as
well as propose improvements. This is why I have started with a
bottom-up approach, implementing the lowest layer of the model (actions,
concrete targets, rules), now trying to wrap my head around the concept
of generators, to layer automatic target generation on top. This is not
only important for my own understanding, but (so my expectation) will
help others, too:
* it will allow end-users to pick exactly the build system interface
they need, cutting out any abstraction they don't want or need.
* it will make it much simpler for b2 developers / maintainers as it
becomes easier to reason about the logic encapsulated in each layer
separately.
* it will make b2 flexible to adapt to new domains as lower layers can
be reused while upper layers can be replaced / adapted / customized.
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
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