Hi, 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! -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
As far as the 'kernel' is concerned, I don't actually care as much whether it is Scons or bjam or whatever. The single most important aspect to me is the user interface, i.e. the language to write Makefiles in. I very much like the idea of making this language python. Unfortunately even scons use a pretty non-pythonic approach for how to write Sconscripts. But still, it is python, and thus easily extensible by anybody with a minimal efford. On the other hand, I find Jamfile syntax quite hard to read. I'm not sure about the current state of its documentation, but the very fact that it is a new language to learn is unfortunate. I very much like the idea of a framework of toolchains as provided by boost.build, and I have proposed to port it to scons in the past. I also like the high-level approach of boost.build to provide a number of (naming and file system) conventions to make the life of everybody easier. I don't understand the boost.build architecture well enough to know which of the above is about bjam, and which about boost.build (or, what boost.build really stands for in the first place). I believe a good essay discussing the boost.build design from a user's perspective would help. In particular, as boost.build is known as the 'build system for the boost libraries' (which may be a misconception) it would help to understand the various components of boost.build, how they interact, and how users can modify them to suite their own project's needs. For example: * Can boost.build be used to build boost-unrelated projects ? * Can boost.build be used to build python projects (or any language in fact) ? * Is boost.build flexible enough to adapt to conventions that may exist when building software using language XYZ ? * Can boost.build be used to package software (similar to python's distutils) ? * How flexible is boost.build with respect to the build tree directory structure and file names ? Regards, Stefan
David Abrahams wrote:
I use scons for my projects, which include usage of boost. I have not used scons to build boost itself, although I have built some of the stuff that was placed outside the boost tree using scons. I guess there are 2 questions: 1) scons vs make 2) scons vs bjam I suppose for boost, issue 1 is moot. I assume boost doesn't use make because make isn't very portable (to no-unix-like environments) So, that leaves issue 2. bjam: It looks very baroque. I don't know anything about it. I don't have much interest in learning yet another build system that I'm pretty sure I'd never use for any other purpose. scons: Does pretty much everything I want. It is quite portable, because it is python. If you have python you have a working scons. The "makefile" equivalents _are_ python scripts. Therefore, you can do anything you can do with python in your scripts. That means, you can easily, portably, do anything at all. scons has some (minor) limitations. You can have build dirs separate from src dirs, but there are some restrictions on the arrangement of those directories.
I use scons for my projects, which include usage of boost. I have not used scons to build boost itself...
Same here. I tried bjam and found it very hard to understand. Scons was appealing as I knew enough python to get it to do whatever I needed. I only use on one platform (linux), whereas Boost has a need for multiple compiler support, so I have no idea how it is for that. My biggest complaint with scons is that it decides the compile order: I wanted unit tests to be compiled and run in the order I defined them (i.e. from quick and simple to slow and complex). But if 20 exes need recompiling due to a header file change, it grabs all 20 names, and then compiles them in arbitrary order (probably alphabetical order). So to work around that I have python loops adding artificial dependencies, so that each unit test exe depends on the previous unit test exe. The downside of that is I have bypassed all scons cleverness: if I change a file only the first and last unit test depend on, it still has to compile and re-run all unit tests in between. So, for my needs, I give make and bjam 3/10, and scons 5/10. Darren
David Abrahams wrote:
Well, SCons supports distributed building and binary repositories - that's a MAJOR selling point. And Python is much nicer than jamfiles. PS: there's also mxx_ru (http://eao197.narod.ru/mxx_ru/) it's a build system based on Ruby - it has some interesting features worth attention. Unfortunately, its documentation is only in Russian, but this should not be a problem for Vladimir Prus :) -- With respect, Alex Besogonov(cyberax@elewise.com)
On Tue, 13 Sep 2005 18:46:08 +0500, Alex Besogonov <cyberax@elewise.com> wrote:
Another Python-based build system I like a lot is A-A-P (http://www.a-a-p.org). I haven't played much with SCons, but judging from the SCons documentation, A-A-P is a lot more powerful. I've found A-A-P to be indispensable for my builds, as well as other things like web page publishing. -- Be seeing you.
David Abrahams wrote:
not a flame, but some test results (Noel Llopis' Blog) shows a few interesting results: http://tinyurl.com/7fdns (www.gamesfromwithin.com) These are updated from previously. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
David Abrahams wrote:
I thought it was harsh as well. Here are a few comments: Ant/Rant outperform Jam on full builds even though he claims Jam is the fastest performing build system. BBv2 and SCons are aimed at being truely platform independant, i.e. one script will work for everything, whereas the others need work on your part to get that or only support one target. I agree with him that there is a learning curve when learning Jam/BBv2, but you get this with learning any new language. He says to avoid BBv2/SCons because of performance, but performance is only one factor. [As a note, how much of a performance penalty is there from BBv2 and SCons being built on top of and run from a scripting engine?] What I like about BBv2 is that I can create a hello world application in 1 minute! The jam file: exe hello : hello.cpp ; install . : hello ; # copy hello.exe to this directory hello.cpp: #include <iostream> int main() { std::cout << "Hello World!" << std::endl; return 0; } and most of that is writing hello.cpp! With this, I can now build debug and release versions - and build on any supported C++ compiler/platform - as easily as changing the command line, BBv2 takes care of the rest. Make and Jam don't give you this out of the box. I have lost count of the number of times I have run into problems with incorrect project settings for MSVC projects, most of which are due to the IDE defaulting to the current configuration (debug or release) instead of editing all configurations. BBv2 (and I assume SCons has this as well) allows you to set project wide settings (e.g. include paths) that are inherited by all targets in this directory and below. You can't do this with the other build tools as far as I am aware, or doing so is complex and unmaintainable. Also, BBv2 (and SCons?) works out the build dependancies for you based on how targets are associated, so if you add another dependancy on one of the targets, you don't need to change the build order as you would in *Ant. (MSVC does dependancy analysis, but only for the current solution and you can't nest solution files). It would be interesting to have more data from large build projects and timing/profile data for these. Q: Is it possible to get profiling data for bjam and BBv2 to see what parts of bjam and BBv2 are taking the most time. Also, I don't believe that BBv2 has incremental build support. I wonder what this and pre-compiled header support would do to the timing data. - Reece
"Reece Dunn" <msclrhd@hotmail.com> writes:
I didn't think Scons was trying to achieve that. IIUC you still deal with many platform specifics when writing Sconscripts... no?
I agree with him that there is a learning curve when learning Jam/BBv2, but you get this with learning any new language.
Yes, but we ought to be doing more to make it shallow. I am about to start posting editorial review commentary on our documentation. I hope that many on this list will participate, so we can make BBv2 much more usable.
He says to avoid BBv2/SCons because of performance, but performance is only one factor.
Well, yes. The other factor for most people is "how easy is it for me to get it to do what I want?" If the system is complex and hard-to-understand, it won't be easy to use, so we may be failing on both counts.
[As a note, how much of a performance penalty is there from BBv2 and SCons being built on top of and run from a scripting engine?]
Some, but I think for BBv2 that only hurts to the extent that we're trying to do something smarter and more abstract than what people do with the other systems. Gnu Make, too, has a kind of scripting engine in it. However, some of its primitives are more closely directed at the problem domain.
Heh, with make I think you might not even need a makefile for this one ;-) $ cat > foo.cpp #include <iostream> int main() { std::cout << "hello, world!" << std::endl; return 0; } dave@i9300 /tmp $ make foo g++ foo.cpp -o foo dave@i9300 /tmp $ ls *ake* ls: *ake*: No such file or directory See?
Now you're talking... but: "changing the command line" isn't easy unless you can come to grips with the system, and we've made that a bit too difficult.
That's also true.
Yes, pass -d+10 on the command line.
What do you mean by "incremental build support?" -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
I am not familiar with SCons, only what has been discussed on the Boost mailing lists, so you are most likely right.
Especially first time users - what problems/issues they have found getting started.
I find BBv2 makes it very easy to add or update targets. I am using it on several tools, libraries and applications I have been developing at home. I have even written a Jamfile for XPDF :). The difficulty comes when you want to do something that's not provided out of the box and have to dig into the internals. Adding features is straightforward and there is a tutorial in the docs on adding features. If you need to write a custom generator or use a generator, it is less clear what you need to do, or which generator does what you want. Another thing that can be daunting is the error messages. The actual location of the error could be stuck inbetween BBv2 internals that make little sense to the novice.
I think Volodya and Rene have pointed out the areas that are of issue (similar string lookup and creating temporary batch files). It would be interesting to see what would happen if the batch files were ditched and the commands executed directly through bjam, your friendly build system, soon to be python script engine and command shell ;)!
I was giving a simple example. BBv2 allows you to write complex build projects that are much shorter than other build systems (especially the XML-based Ant and Microsoft VC project files). Also, there are less things I need to worry about (like getting the right version of the runtime library).
The BBv2 documentation leads you through building release and debug versions, as well as some other things. Once you are familiar with the "<feature>value" syntax and that on the command-line it is "feature=value", as long as you know the feature and its values, you are away! :) Also, I don't need to think "okay, so how do I disable RTTI for compiler X", it is always "<rtti>off"/"rtti=off".
Thanks :).
As noted in another post, I meant the "incremental linking" feature of VC (and other compilers?). - Reece
"Reece Dunn" <msclrhd@hotmail.com> writes:
I think this has a strong relationship to something troy d. straszheim just posted: "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." -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Tue, 20 Sep 2005 17:08:04 GMT, Edward Diener wrote:
Correctness comes first, but I think the article was reasonably fair. The author is trying to find a build system to solve a real-world problem. The requirements that it should be fast, simple to customise for other platforms and tools and perform as well on incremental builds as on full rebuilds seem a reasonable place to start. If the synthetic benchmark he uses seems unfair, please produce some constructive criticism as to how it can be made more realistic. Returning to the title of the thread, the only things I've used BBv1 and BBv2 for are building Boost itself, and some toy projects (the exercises from the TMP book). Based on that (limited) experience, I would not consider [b]jam or BoostBuild for any serious work. Producing a language with more baroque and undebuggable syntax and semantics than 'make' takes some doing. I think that the effort expended on BBv1/BBv2 would have been far better spent on fixing the performance issues in scons. AndyM
Andy Moreton <andy.moreton@artimi.com> writes:
I think that the effort expended on BBv1/BBv2 would have been far better spent on fixing the performance issues in scons.
Just for the record, BBv1 predates Scons by some considerable time. When I began that project I tried to get Steven Knight to start on Scons with me and at the time he wasn't ready yet. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Kevin Wheatley wrote:
Interesting, but: 1. They are skewed a bit. 2. They don't represent much 1. They are skewed, because performance measurements is hard. The only way to know for sure is to test on your real data, everything else needs justification that the test is adequate. For example, the specific test has a lot of files with the same name, which hits specific non-scalability in V2. Originally, test required 33 seconds on my system. A one line fix removed 6 seconds from that time (-20%). 2. The don't represent much, because little time was invested in optimisation. After all, I can rewrite critical parts in C, for a 100x speedup of those parts. Just today, spending something like an hour I brought the running time from: Real time: min 34:400, max 37:60, avg 35:412 User time: min 33:350, max 35:230, avg 33:832 to Real time: min 25:670, max 29:390, avg 26:838 User time: min 24:750, max 27:860, avg 25:644 (bjam -n, average over 5 runs) That is -25% for real time. Certainly, more improvements are possible, but at the moment V2 appears to be faster that V1, and the primary priority is ease-of-use, so that we can switch to V2 for Boost. I'd surely be willing to speed things up, but those folks did not even contact us about their findings (and my email to their mailing list is still hanging in moderation queue). I'm not sure they contacted SCons developers, either. - Volodya
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
participants (13)
-
Alex Besogonov -
Andy Moreton -
Arkadiy Vertleyb -
Darren Cook -
David Abrahams -
Edward Diener -
Kevin Wheatley -
Neal Becker -
Reece Dunn -
Stefan Seefeld -
Thore Karlsen -
troy d. straszheim -
Vladimir Prus