Re: [boost] Scons users?

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-20 12:42:02

David Abrahams wrote:
>"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)
> >>
> >>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:
> >
> > 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 am not familiar with SCons, only what has been discussed on the Boost 
mailing lists, so you are most likely right.

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

Especially first time users - what problems/issues they have found getting 
started.

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

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.

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

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 ;)!

> > What I like about BBv2 is that I can create a hello world
> > application in 1 minute! The jam file:
> >    [snip]
> > and most of that is writing hello.cpp!
>
>Heh, with make I think you might not even need a makefile for this one
>;-)
>   [snip]
>See?

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

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

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

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

Thanks :).

> > 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?"

As noted in another post, I meant the "incremental linking" feature of VC 
(and other compilers?).

- Reece