• What is SBuild?
• What makes SBuild different?
• What about the name "SBuild"?
• History
• Who is the main customer?
• How can it be comprehensive?
• Is SBuild free software?

[up one level]

SBuild is a build tool for software products. It is a high-level, comprehensive and reliable build tool. It is designed to pitch the right feature sets to different categories of users. It is designed as an open framework in order to easily support new types of builds. Finally, it implements an unprecedented amount of features out of the box for the day-to-day work of the software developer.

[back to top]

"SBuild is comprehensive" means two things:

1. It serves several categories of users with very different needs. That ranges from the casual builder to the release process designer. That includes the porting engineers, a category often abandoned to their own by build tools. That includes also users who never leave their fetish IDE.
2. It is meant as backbone of a large range of different build processes. That goes from simply maintaining in sync a copy of a directory to massive number-crunching model building. That includes, of course, software product builds.

"SBuild is high level" means it has features to reduce the user effort to use it. That means quick, intuitive pick up for occasional users and smooth learning curve for heavy users.

SBuild is reliable means that, if it claims something is "up to date", than the chances are very high for that claim to hold true. High enough for process certification use cases, for example.

[back to top]

SBuild stands for "SCons-based Build". SBuild is a tool implemented as a plug-in into another very capable, lower level tool called SCons. The relationship between SBuild and SCons is described on a separate page here.

  [back to top]

Me, Adrian NEAGU, I fulfilled the role of release engineer in Nuance for several years. My group and our products history, as far as the build tools is concerned, reads like this:

1. many years with make (from bare make to makefiles and IDE project files generated from XML build descriptions)
2. about one year trying make alternatives, until we settled on SCons
3. a few years with SBuild and still running (from Jan 2005).

  [back to top]

Many people judge a piece of software by its main customer. That approach is meaningful. The mission statement is sometimes not written down and the implicit mission is then to serve best this main customer.

SBuild main customer today is the Embedded Software division of Nuance. This Embedded Software part of the company is busy producing Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) software engines, the best in their class by both customer benchmarks and market share. Precisely, SBuild was born in the Automotive ASR group, the team that makes the software that allows you to dictate a destination to the GPS device in your car.

This should allow you to already make an idea about the kind of requirements SBuild was designed to serve in the first place. Our product is a medium-large piece of C code and OOC code (OOC = our proprietary Object Oriented C). The team has about a dozen researchers, a dozen software developers and yet another dozen of porting engineers spread on several sites around the world (the numbers fluctuated over our more then 10 years in business and they still evolve).

Working in embedded software, one important characteristic is the fact that our software goes to many different target platforms, some of them with unfriendly compilation tool chains. There are very few build tools available that cater specifically for cross-compilation. For example separation of the settings of the host platform from settings of the target platform is rara avis feature.

Another characteristic specific to speech processing is a lot of data compilation. That can be a small task, like compiling a text grammar to a speed-efficient binary format. And that can be big. The production of acoustic models and language models are in fact compilations of large databases into one file (and that takes several days of processing on a capable computing farm).

More recently, SBuild is used by Red Bend Software to build system software for mobile phones.

  [back to top]

It is a known hard fact that "one cannot be good at everything at the same time". So how can SBuild be good in all fields where it claims to be so good?

The key is decoupling and factoring out. The master idea of SBuild design in decoupling things that can be dealt with separately. The concepts like SBuild targets, SBuild toolkits and SBuild packages are central to this "decoupled" design. More on that in the design description.

  [back to top]

No, SBuild is not open source. It is property of Nuance and Nuance delegated some precise rights on SBuild to Abalog, a small service company, mainly for the purpose of further SBuild development and maintenance. You may obtain a copy of the sources at no cost, including for production use of the tool, but only by entering an agreement with Abalog.

[back to top]  [up one level]