Re: [Boost-users] Scons users?

"Reece Dunn" writes:

David Abrahams wrote:

...

Kevin Wheatley 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.

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

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!

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?

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.

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.

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.

That's also true.

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.

Yes, pass -d+10 on the command line.

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.

What do you mean by "incremental build support?" -- Dave Abrahams Boost Consulting www.boost-consulting.com