• Categories of users
• The casual builder
• The code developer
• The porting engineer
• The release engineer
• Kinds of builds
• Code builds
• Model training
• Video games data
• Document production

[up one level]

SBuild, like any other build system, has very different usage scenarios for the different users. It is important for each user to understand "what kind of user am I?" so that he/she can use or learn the tool as efficiently as possible. This page describes the typical users and their needs from a build system. While some features are generally desired, like speed or reliability, other features are specific to some users.

[back to top]

Most of the users belong to this category. They want to use the tool just to build something. They don't really care about how it gets built, they care for the output of the build. They look first for the big-go-button and they have almost no interest in other features of the system. They may take profit of some trivial introspection, like "What can I build here?". Software distribution as sources is one such usage.

[back to top]

This is the next larger category after the casual builders. They have higher requirements from the tool. They do frequent small incremental rebuilds. This makes avoidance the most important feature for them. Because they add new targets, they also care about the syntax of the build description. They would actually be happy to have wizards helping with that task. They care about specifying the flavor of the software they build. They need better introspection: they need to know which source files went into some compiled target and where are those sources on disk. They would like to not care about any lower level detail like toolchain installation.

  [back to top]

These users are opposed to the code developers in many respects. Their task is to make a software run on a different target platform. So they extend the build system with support for new compilation toolchains and new target platforms. Factoring out the platform-specific aspects is the most important feature for them. They care most about how the C/C++ targets are implemented (the C/C++ toolkit for SBuild or the C/C++ rules for "make"). They care much less about avoidance. Although they don't have a particular interest in the syntax of the build descriptions, they still care  because, after adding new toolchains, they will port one or several C/C++ products, meaning they will change build descriptions. They need a dedicated kind of introspection: "What places do I need to customize/change?".

  [back to top]

These are rare users with the most demanding requirements. They care about the entire system because their tasks are end-to-end builds of deliverables. Among their specific concerns are: automation, extensibility (how easy it is to specify new kind of builds), reporting (logs, comparison of builds, publishing of results), guide lines enforcement in build descriptions, etc. They love the introspection features that allow to present/explain the entire flow to others.

  [back to top]

A build tool is a file-flow maintenance instrument. There are many different processes that are producing files and, by way of consequence, are using build tool. These processes are different in several respects (for example, more or less parallel in nature, deeper or shorter in number of steps, etc.). Here are a few typical examples.

  [back to top]

These are software products builds. They are the result of the compilation and linking of genuine inputs called source files.

• C/C++ builds. The C/C++ builds are the process of producing a few binary files (executable files as well as dynamic loading libraries) out of C/C++ source files. Usually there is also some associated data compilation (for example, the "resources" on the MS Windows platform). For embedded software, the build usually ends with a memory image that is burned to a Flash EEPROM. Other programming languages follow a very similar build process (Pascal, Ada, D, etc.). Yet a broader category of languages are translated to C code first (and can further be compiled from there): Matlab, Eiffel, Fortran, etc.
• Other code builds. Java builds usually end with a jar file (a zip-like archive containing all the compiled byte-code, one file per class). Python builds can end with a zip with byte-code (pyc) files or with an native executable (such Python build is called "freezing"). Other scripting languages follow the same model: Perl, Ruby, etc.

  [back to top]

The statistical training of both the acoustic model and the languages model are large compilations. They are "large" both by the number of genuine input files and by the number of successive steps and their duration. Some trainings may takes many days of CPU on a capable computing farm. Unlike the code builds, some steps are manual. Models are "tuned" for best performance, so they have flavors controlled by some sheet of parameters, often many more parameters than a code build.

  [back to top]

A typical build is the data compilation involved in the construction of 3D virtual worlds frequently used in video computer games. Many artifacts (textures, geometric models, etc.) are developed separately are compiled into a speed-efficient binary format that is used loaded at run-time by the game. Here frequent rebuilds are usually performed, similar to code builds.

  [back to top]

Although most documents are maintained manually, end-of-line conversion to different file formats and/or publishing to a Web site are frequently done by a build system. One example are the documents authored in the DocBook XML format. Another typical example of document "building" is the Tex and LaTex document authoring.

  [back to top]  [up one level]