From: troy d. straszheim (troy_at_[hidden])
Date: 2005-09-20 12:25:00
> David Abrahams wrote:
>>On the Boost.Build list we were just discussing the fact that some
>>people otherwise inclined towards Boost have chosen Scons over
>>Boost.Build. It would be useful for us to understand some of the
>>reasons why, if some of you wouldn't mind letting us know. No flames,
Not a flame:
I had to go shopping for a build system for a large C++ project about a
year ago, and I also played for a few days with scons, a few days with
boost.build, a little with regular jam, makepp, some others. I had
already been using make for longer than I care to admit. I just took
them each out, kicked the tires and slammed the doors, so to speak. My
approach was to start playing with tutorials and get a feel for these
utilities based on the docs, the number of bugs I found, and whether I
got the feeling that I was coming up the learning curve. I ended up
just overhauling our makefiles.
I pretty quickly wrote off scons due to lack of docs, same with makepp.
I remember having the feeling that the reason scons existed was that
somebody didn't like make syntax. Normal jam had the feeling of being
mature and solid, which I liked, but there weren't lots of docs, and I
decided to skip ahead to the boost version.
I jumped in to bjam prepared to invest a lot of time. As a longtime
make and perl user, a little funky syntax didn't spook me. If it does
the job well I'll go for it, I thought. I still believe there's a way
to solve our problem with bjam more elegantly and maintainably than our
current make setup, but I was unable to estimate whether I would hit
showstopper problems later or not, and it seemed that in any case, I
would be unable to find somebody else to maintain it, as there was no
comprehensive documentation to hand over with the jamfiles. Beyond
"hello world", I found little cookbook-type documentation, and no
examples that the build system was in use on real-world projects other
than boost, and in boost the fact that v1 and v2 are quasi-superimposed
on one another was spooky. I never got the feeling that I was really
coming up the learning curve. One good thing about "make" is that the
docs are very thorough, they fit all on one web page, and there are
examples everywhere you look and that there are very few bugs. Well,
when you start doing crazy stuff, you can hit bugs, and we now have to
use a particular recent checkout of GNU make. :/ But you'll agree it's
The old quote from Brooks comes to mind: "Because ease of use is the
purpose, this ratio of function to conceptual complexity is the ultimate
test of system design." This is near the quote "I will contend that
conceptual integrity is *the* most important consideration in system
design. It is better to have a system omit certain anomalous features
and improvements, but to reflect one set of design ideas, than to have
one that contains many good but independent and uncoordinated ideas."
(The Mythical Man Month p. 43, for those who are interested).
This may also be what I found lacking in what bjam docs I did find; I
got no sense of the architecture of the thing, and therefore no sense of
whether I could express my problem well in the context of this
architecture. There were multiple jamfiles hanging around, some in
distant directories, there was grist (?), I
<@saw!some!strange!messages>, and I remember being struck by mention of
polymorphism somewhere (perhaps in a comment in a jamfile). How did it
all fit together? I also didn't have the feeling I could completely
trust the docs. I fairly quickly found basic behavior (I think it had
to do with the way bjam searches for jamfiles when it starts up, but I
don't really recall) that didn't seem to match the docs I was reading.
I recall wanting to read about debugging Jamfiles, specifically how I
could use the debug flags to determine what was going on, so that I
could just reverse engineer things that weren't documented.
I think that if there were an O'Reilly/cookbook type text, with lots of
examples, I would have gone forward, even if the architecture were
disjoint, on the notion that it just *has* to somehow be an improvement
over make. Really smart people are working on it. It's boost.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk