Re: [boost] Scons users?

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-20 10:37:55

"Reece Dunn" <msclrhd_at_[hidden]> writes:

> David Abrahams wrote:
>>Kevin Wheatley <hxpro_at_[hidden]> 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_at_i9300 /tmp
  $ make foo
  g++     foo.cpp   -o foo

  dave_at_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