Re: [Boost-build] Future development

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-04 02:56:20

Benjamin Kosnik wrote:

[you snipped some author names here]

>>> I think the answer is "bjam". As you said above, the Jam language is
>>> essentially undocumented. It's also a rather odd language, and its
>>> eccentricities are exaggerated by the object-oriented system BBv2
>>> has built on top of Jam. We picked Jam several years ago, when
>>> Perforce was still working on it and it looked like there would be
>>> an active community around Jam. That hasn't happened, and we're
>>> somewhat isolated in our use of this language and build tool,
>>> forced to customize and maintain "bjam" on our own.
>>
>> You surely understand that with core in Python, the amount of
>> maintenance and customization necessary for bjam will be greatly
>> reduced, almost to the point of being zero.
>
> Famous last words.
>
> FWIW, how is a rewrite into python addressing Doug's
> meta comment about the Jam language itself?

IMHO, I don't believe that the problem is related to the declarative parts 
of the Boost.Build Jamfiles (i.e. "exe", "project" and their "requirements", 
"usage-requirements" etc). This is what should be retained even with a 
Python (or other) port as description files.

Implementing and using algorithms and extensions is the hard part of using 
Boost.Build (due to the Jam language); method calls with wrapping "[]" 
(Tcl-esque?), expansion with "$(value)" (Make-esque?), remembering to end 
the statement with a space before the semicolon (Jam-esque!); writing own 
custom generators; not having a standard library; not having access to a 
multitude of third-party libraries; not having a large community, ... did I 
mention docs, docs and docs?

I'm sure that a (e.g. Python) DSL (as Dave A pointed out) can be better 
designed than SCons, but I doubt they can be equally readable to BBv2 
Jamfiles (I'd be happy to be proven wrong). So why not stick with Jamfiles 
as the first step?

An evolutionary approach which enables getting something done is probably 
better than a perfect design that will never make it into a "ready" state. 
I'm aware that BBv2 took, and is still taking, ages to get into current 
state (absolutely no offence meant to the authors) but - being able to 
extend, debug and test the build system using a "real" language could only 
improve the situation.

Just my 0.02EUR.

/ Johan