• SBuild is an SCons application
• SBuild heavily relies on SCons
• SBuild aims to be an add-on
• SBuild is an SCons elevator
• Serving differently different users
• SBuild is SCons for the masses
• SBuild takes some different directions
• Why didn't contribute more directly to SCons?

[up one level]

Before saying how SBuild is different and why raw SCons was not enough for us, let’s say first a word about how important and how useful SCons was, is and will be for us and our needs.

[back to top]

SCons is the engine behind SBuild. This is a deliberate choice. The choosing took almost one year and, at the end of the selection process, SCons was the best fit by far. We tried several build tools. Some were rather OK but were lacking a few features that we wanted (Ant, Jam). Some were disappointing (A-A-P, MS Build, automake). Some were rather OK but way to far from anything in our group culture (Omake/Ocaml). We also looked at related tools of different nature (CMake, Maven, distcc). It must be mentioned also that we had some bias for Python (already used in our home-grown build system, based at that time on XML descriptions, the make tool and Python). Find more on our journey among build tools in this article at Freshmeat.

Today SBuild carries out a few trivial actions on targets without starting SCons (like "list sources", "find in files") but it does start SCons for all the interesting stuff (C compilations, "what&why” query, etc.)

[back to top]

SBuild is designed to be a non-intrusive add-on to SCons. SBuild tries hard to be a "civilized" SCons application, a rather challenging task given the scope and ambition of SBuild (see more details in the section on SCons).

SBuild code is actually "dropped in" as a directory, SCons/SBuild, next to the directory SCons/Script implementating the "sconscript" functionality of SCons. We always used only in the "scons-local" distribution of SCons. SBuild is small compared to SCons (SBuild ~5000 lines, SCons ~25000 lines on January 2005, when SBuild first went into production. SBuild grew, SCons grew and I think the proportion is about the same today). More important, all SBuild code uses SCons code through the official, documented SCons API (with one tiny exception where the completeness of that API may be debated). Implementing and extending SBuild is really a strong exercise in SCons programming.

The decision to make SBuild a add-on has a downside as well. We do inherit directly shortcomings of SCons. Including the bad reputation of slowness in null builds. Yet, we deemed important to avoid yet another fork, so we decided to accept SCons as it is (except a very few minor fixes).

  [back to top]

"SCons elevator" is our own jargon to describe the fact that SBuild raises the level of abstraction compared to the use of raw SCons. We see SCons as a "core" build engine and SBuild provides some "porcelain" around it.

  [back to top]

SCons fits best the following setup: There is a software product developed by a team and there is a build master. He is the one to develop, to maintain and to extend the build description. He is the one to port the software; he is the one to support new toolchains. He replaced hundreds of makefiles with a Python script of hundred lines (or several smaller scripts). Most other people are not interested in the build description itself and they are happy as long as they can build "their stuff" in their corner faster and safer than before. The more compact the build description is, the more efficient the build master is. But also the more cryptic it is for the rest of the developers. For somebody having 0 SCons knowledge on top of 0 Python knowledge, adding 2 lines in a 200 lines script is frightening, even if, after doing it, they will admit that it was not a big deal.

This is not depreciatory. This is a good setup and it serves excellently a large number of software projects of different sizes.

SBuild tries a different approach. For SBuild, there are developers (who want to add targets), there are porters (who would like to not touch the targets), there are release engineers (who may invent new types of targets) and that small world shouldn't step on each other toe (for example, by changing the same place in the same file). Moreover, there will be build description generators (wizards) and there will be GUI to the build tool (IDE) who will both want to mess with the same build description.

  [back to top]

SBuild is an attempt to bring SCons to a larger audience. For this purpose, it provides more features out of the box (use without any changes) and lower the knowledge entry threshold (when changes are needed).

1. Example of "more features out of the box": a casual user may build flavors of a target ignoring how to implement a variant. Any user may "search string in files" or "run target" without knowing precisely locations on disk. There are many added features, from trivial one like "list sources", "do forced build", "list C functions in a C source" to quite advanced like "perform a renaming build", "scan for wrong include guards in C headers", etc.
2. Example of "lower knowledge entry threshold": the descriptive nature of a target specification makes that developers usually write their first new target (by copy&paste inside the same file) before noticing that they didn't open any piece of documentation (Python, SCons or SBuild). And this happens while SBuild caters for arbitrarily complex build targets, not just single files on disk. By grouping together what the users "thinks" as one built entity, SBuild fulfills its elevator stated mission and gains a friendlier look&feel.

  [back to top]

While a true SCons application, SBuild departs from its engine underneath in a few "philosophical" aspects. Here are some of them, out of order:

• SBuild uses a different build description approach. The description is still Python syntax but more descriptive in nature (XML style) than procedural.
• SBuild prefers an Object Oriented style API over the flat, C-style API of SCons
• SBuild takes the courage to fight the die-hard make habits (please see this article at Freshmeat). No attempt to mimic make (or to fold into the make culture) is made, despite the potential implications.
• SBuild needs Python 2.2.3. The SCons minimal requirement, 1.5.2, will not do. This came from a planed different approach for bootstrapping (generate shell-based build scripts for those low-end, old host platforms). Recently SCons accelereated its move towards Python 2.2 as minimal requirement.

There are also differences that resulted as a matter of facts. These are features of SCons that SBuild didn’t surface yet because they were not useful in our development environment (for example, features dedicated to different version control tools). And finally, there are, of course, many others differences in practical aspects, like for any two independently developed pieces of software. For more details, see also the section of this site on SCons.

  [back to top]

There were several factors that contributed but nothing that I could qualify in all honesty as a good reason. Here are some reasons:

• A decision to not make SBuild open source software
• A desire to narrow the focus of our efforts to one relatively small group (about 50 developers, in a company that has over thousand developers)
• A distance between the development environments. SBuild is developed in our usual environment (ClearCase + TWiki + Bugzilla + propietary nightly dashboard tool) which is quite different from the mainstream open source environment

The first two factors are typical in corporate software development. While the first is understandable, the second is more debatable. For example, as a consequence of the second, we stopped following SCons at version 0.96.1. It follows that SBuild still uses env.Copy() instead of env.Clone() and that has a significant impact for all users, including those we claim that we focus on. But, as the proverb goes, "better late than never" and this Web site is a small start. SCons may profit from SBuild, if not as a complete plug-in, at least as any framework can profit from a large application of it.

  [back to top]  [up one level]