Re: [boost] Scons users?

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,
>>please!

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

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.

HTH

-t