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