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
I don't remember all of the details, but a while back we went through the experiement of implementing parts of our build in both bjam and scons. Probably the single biggest benefit that scons had over bjam (and the other options we looked at) was the use of python. It was very natural and comforting, whenever we can across a wierd corner in the build, to just write some python code to deal with it. I seem to remember scons being better documented, although it was perhaps just more intuitive. In the end, both build systems worked just fine, IIRC, and we stuck with scons for the reasons above. Since then, we've come to place a great deal of faith in scons. It's a great crutch, in fact, as it's extremely good at determining when stuff is out of date (this also makes it pretty slow sometimes). I've found, for instance, that bjam doesn't seem to notice when I change compile-time definitions (i.e. for the signals lib namespace), while scons does. Austin Bingham On 9/13/05, David Abrahams <dave@boost-consulting.com> wrote:
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 <http://www.boost-consulting.com>
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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!
I have been using Scons more for tiny projects* than for large ones, and I am still somewhat ignorant about Boost.Build, so I can't give a fair comparison. But people aren't fair, so I think the data points are still valid: 1. Scons is a nice framework embedded in a general purpose programming language. So, you get the benefit of a DSL that does 80% of the job very nicely, but you've got all that is Python for the 20% that doesn't fit -- and the two parts integrate naturally. I moved from Ant to Scons and liked that Scons provided lots of high-level functionality but didn't straightjacket me into abstractions that didn't fit my situation. 2. My standard SConstruct file is 4 lines (2 imports, 2 statements). I get a full dependency analysis, can make full use of ccache and distcc, and run my unit tests after the build. I can't imagine life being better. :-) 3. Boost.Build started out life as a fork (right?), and I haven't noticed many other projects outside of Boost using it. Scons seems to have more "momentum". 4. Boost.Build docs don't/didn't offer the trivial example of how to get "Hello, World" to build. Compare: http://www.boost.org/tools/build/v1/build_system.htm#getting_started with: http://www.scons.org/doc/HTML/scons-user.html#AEN239 5. A fair amount of traffic on this list seems to be from people who have trouble with Boost.Build. Of course, I'm not subscribed to the scons users list so this isn't fair, but my perception was that Boost.Build would have a steeper learning curve. I'm sure Boost.Build is a powerful system and can do the job... it just seemed to require more thought to get running the first time, and I wanted to devote my thought to writing code. Hope this helps, Jon * The majority of my tiny projects are stub programs to play around with all the other Boost libraries! :-) -- Jon Stewart stew1@ellipsis.cx
David Abrahams <dave <at> boost-consulting.com> writes:
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!
You'll want to read Noel Llopis' blog, particularly this entry: http://www.gamesfromwithin.com/articles/0506/000092.html The above article contains hard performance numbers comparing Jam, Make, Scons, and MSVC. It has also been discussed many times over the last year or so on the SWEng list. http://news.gmane.org/gmane.games.devel.sweng The main discussion points have been about fast incremental builds, distributed builds, cross-platform (PC, XBox, PS2, GameCube), integration with existing development tools, and integration with binary asset build tools. Someone else mentioned the importance of support for precompiled headers, Edit-and-Continue support is important too. I'm not sure what the current state of support in Boost.Build is. Parveen
Parveen Kaler <pkaler@relic.com> writes:
David Abrahams <dave <at> boost-consulting.com> writes:
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!
You'll want to read Noel Llopis' blog, particularly this entry: http://www.gamesfromwithin.com/articles/0506/000092.html
The above article contains hard performance numbers comparing Jam, Make, Scons, and MSVC.
I don't think that's much help. It doesn't cover Boost.Build at all (it only bears passing resemblance to Perforce Jam anymore), and doesn't discuss many of the issues of concern for the developers of Boost.Build (http://www.boost.org/tools/build/v1/build_system.htm#design_criteria) Of course, it may be that the world at large doesn't care about those things :) -- Dave Abrahams Boost Consulting www.boost-consulting.com
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!
Just something I came across on another mailing list you may be interested in. Martin ----------------------------------------------------------------- I keep meaning to put up a followup article to the build system one. I consider a bunch of other build systems, including Boost.Jam. I looked into Boost.Jam because it was supposed to be the great followup to Jam, with all the little things fixed and support for a bunch of very useful things out of the box. Well, somebody dropped the ball big time with that. First of all, I found Boost.Jam to be extremely complex (nothing like the original Jam, which wasn't exactly simple either). But the big problem was performance. Here's a comparison of a build with the same set of files: Jam on Windows: - Full rebuild: 6m 52s - Incremental build: 3.1s - Incremental single libray: 0.3s BoostBuild v2 (3.1.10) on Windows: - Full rebuild: 12m 03s - Incremental build: 55.5s - Incremental single libray: 2.0s I find the difference in performance simply baffling. How bad can you screw up the performance of a full build using the same compiler??? Anyway, as I said, I'll put up a full article this weekend including results for Boost.Jam, Ant, Nant, VS2005 and a few others. --Noel Games from Within http://www.gamesfromwithin.com -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.24/100 - Release Date: 13/09/2005
Martin Slater <mslater@hellinc.net> writes:
Well, somebody dropped the ball big time with that. First of all, I found Boost.Jam to be extremely complex (nothing like the original Jam, which wasn't exactly simple either). But the big problem was performance.
Here's a comparison of a build with the same set of files:
Jam on Windows: - Full rebuild: 6m 52s - Incremental build: 3.1s - Incremental single libray: 0.3s
BoostBuild v2 (3.1.10) on Windows: - Full rebuild: 12m 03s - Incremental build: 55.5s - Incremental single libray: 2.0s
I find the difference in performance simply baffling. How bad can you screw up the performance of a full build using the same compiler???
This test was subsequently debunked as non-representative: it happened to hit an odd performance corner in Boost.Build because of the way artificial source file naming interacted with some of Boost.Jam's internals. That issue has since been fixed. http://article.gmane.org/gmane.comp.lib.boost.build/10160 -- Dave Abrahams Boost Consulting www.boost-consulting.com
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!
We use MPC, http://ociweb.com/products/mpc It takes a different approach to the problem by generating various build tool specific project files. It currently supports the following: Generic Make, GNU Make, NMake, Visual C++ 6, 7.1 & 8, Embedded C++, & Borland Make The nice thing about it is you can use MSVC++ and precompiled headers when on Windows and GNU Make when on Unix or Linux. It simply generates the Makefile or project file needed from a very simple project description. It was originally created to battle the problem of multi-platform builds of ACE and TAO. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
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, 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 |
Kevin Wheatley <hxpro@cinesite.co.uk> writes:
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, but some test results (Noel Llopis' Blog) shows a few interesting results:
http://tinyurl.com/7fdns (www.gamesfromwithin.com)
These are updated from previously.
Wow, harsh. The numbers aside, I think his commentary is rather flame-ish. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Kevin Wheatley wrote:
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, but some test results (Noel Llopis' Blog) shows a few interesting results:
http://tinyurl.com/7fdns (www.gamesfromwithin.com)
These are updated from previously.
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
participants (8)
-
Austin Bingham -
David Abrahams -
Jon Stewart -
Kevin Heifner -
Kevin Wheatley -
Martin Slater -
Parveen Kaler -
Vladimir Prus