Re: [jamboost] Re: [boost] Scons users?

From: Steven Knight (knight_at_[hidden])
Date: 2005-09-20 11:48:39

Hi David--

>>> 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.
>>
>> True, but that wasn't his aim. Which means one has to take the tests
>> from the POV of using it on one configuration for repeated builds.
>
> And that matches the concerns of most users. AFAIK people like me who
> want to build on 14 compilers at once are freaks of nature.

Or they're buildmasters for large systems.

In a weird way, I'm comforted (*not* in a competitive, ha-ha way)
to find out that Boost.Build has some performance issues. SCons has
gotten beaten up pretty badly for performance over the last year or so,
and people have been pretty quick to point fingers at causes based on
a lot of assumptions and little data: "It's because it's in Python."
"It's because it's MD5 checksumming the contents." "It's because it's
scanning file contents for dependencies." Etc., etc., etc.

Well, I've put in a *huge* amount of time over the last year profiling and
trying to optimize SCons, and although I've found a number of things to
clean up, there simply aren't any smoking-gun bottlenecks. Seeing data
like this strongly suggests that the performance issues of SCons and
Boost.Build are largely because they're trying to solve a much more
complicated set of problems than people normally expect from a build tool:
correct cross-platform builds with multiple variants and tool chains.

Of course, people's expectations are set by a tool that is essentially
optimized for a completely different problem: incremental rebuilds of
source files in a single directory. If people really wanted to compare
functional apples to apples, they should compare Boost.Build and SCons
not to just Make, but to Make+Autoconf+Automake+ccache. Imagine if you
had to run Autoconf every time you built a single object file.

But you're exactly right, there are lots more developers out there
than there are buildmasters, so this perception of performance will
undoubtedly dominate for some time. In the meantime, I've been trying to
back SCons away from *insisting* on a full DAG of the whole source tree
every time, and find ways to allow the user to partition the DAG safely.
There's probably a comfortable middle ground to be found somewhere.

--SK