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