More detailed discussion of some of the Build Engine's characteristics:
The Build Engine can be embedded in any other software
that supports embedding Python:
in a GUI,
in a wrapper script that
or in any other software that
can translate its dependency representation
into the appropriate calls to the Build Engine API.
describes in detail
the specification for a "Native Python" interface
that will drive the SCons implementation effort.
When building/updating the objects, the Build Engine operates as a single executable with a complete Directed Acyclic Graph (DAG) of the dependencies in the entire build tree. This is in stark contrast to the commonplace recursive use of Make to handle hierarchical directory-tree builds.
Dependency analysis is carried out via digital signatures (a.k.a. "fingerprints"). Contents of object are examined and reduced to a number that can be stored and compared to see if the object has changed. Additionally, SCons uses the same signature technique on the command-lines that are executed to update an object. If the command-line has changed since the last time, then the object must be rebuilt.
The output of Build Engine is customizable through user-defined functions. This could be used to print additional desired information about what SCons is doing, or tailor output to a specific build analyzer, GUI, or IDE.
SCons detects build failures via the exit status from the tools used to build the target files. By default, a failed exit status (non-zero on UNIX systems) terminates the build with an appropriate error message. An appropriate class from the Python library will interpret build-tool failures via an OS-independent API.
If multiple tasks are executing in a parallel build, and one tool returns failure, SCons will not initiate any further build tasks, but allow the other build tasks to complete before terminating.
-k command-line option may be used to ignore
errors and continue building other targets. In no case will a target
that depends on a failed build be rebuilt.