[CMake] VMWare on SCons' future

[Brandon Van Every]

On Mon, Mar 3, 2008 at 3:07 PM, Brandon Van Every <bvanevery at gmail.com> wrote:
> On Mon, Mar 3, 2008 at 2:11 PM, Brandon Van Every <bvanevery at gmail.com> wrote:
>  > VMWare is a large commercial project.
>
> >  http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html
>
>  My impression so far is that SCons appeals to a company that wants to
>  program a customized build system, rather than have one off-the-shelf
>  that already works.

Here's an exemplar:
http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258i60.html

"I don't think we'll ever be able to define a model for how tools should look,
or how command lines should be generically specified, that will satisfy
everyone. It's just not possible. After I wrote my original email, I got a
lot of feedback (some through the list, some outside the list) from people
who use the tools exactly in the way that we at VMware do. That is, we don't
use them.

We wrote our own generic command lines, and our own module loading mechanism.
The part of scons we reuse is the machinery to convert the environment
variables into actual command lines, but we don't use any of the built in
variable schema at all. We write our own scanners, and our own builders."

CMake should not seek to emulate this business model.  Let the SCons
guys have it, and let them flounder in it.  For pete's sake they're
arguing in committee bazaar fashion about how to deploy a stable
release cycle.  They're way behind CMake in some areas.  I'm open to
Python, Ruby, or Lua demonstrating something important about scripting
languages and build systems, but the SCons crowd seems so dominated by
other problems that it doesn't seem all that relevant.  They're not
proving anything about Python; in fact, they're proving that Python
1.5 is a serious liability over the long haul.  It's slow and hard to
modify the SCons core.  That's another tidbit somewhere in that
thread, you can learn tons about SCons from that thread.


Cheers,
Brandon Van Every