SCons is a software construction tool (build tool, or make tool) implemented in Python, which uses Python scripts as "configuration files" for software builds. Based on the design which won the Software Carpentry build tool competition, SCons solves a number of problems associated with other build tools, especially including the classic and ubiquitous Make itself.
Distinctive features of SCons include: a modular design that lends itself to being embedded in other applications; a global view of all dependencies in the source tree; an improved model for parallel (-j) builds; automatic scanning of files for dependencies; use of MD5 signatures for deciding whether a file is up-to-date; use of traditional file timestamps instead of MD5 signatures available as an option; use of Python functions or objects to build target files; easy user extensibility.
This paper discusses the goals of the SCons project, gives an overview of the design of SCons itself, describes the development process used, and discusses future plans and directions for the tool.
More than twenty years after its creation, the classic UNIX Make utility and its descendants are still the dominant way in which software is built. Make has maintained this position despite the fact that the intervening years have revealed many shortcomings of the Make model for building software:
The use of timestamps to decide when a file has been updated is imprecise and prone to error, especially across distributed file systems such as NFS.
Builds of typical large software systems still take hours, if not days, despite the tremendous advances in CPU and disk speeds over recent years.
Make maintains static definitions of dependencies in its Makefiles. Much effort has been put into utilities (mkdepend, gcc -M) and schemes (Makefile.d files) to try to keep Makefile dependencies up-to-date, but these only confirm that Make's static dependencies are inherently fragile.
The standard recursive use of Make for build hierarchies leads to incomplete dependency graphs, which must be overcome by manually changing the order in which directories are built, or through the use of multiple build passes.
One need only look at the plethora of helper and wrapper utilities (automake, easymake, imake, jmake, makeLib, maketool, mkmed, shake, SMake, TMAKE) and complete alternatives to Make (Ant, bake, bau, bras, Cake, Cons, Cook, Jam, jmk, jus, makeme, mash, MK, nmake, Odin, VMake) that have been created over the years to realize that vanilla Make is not satisfying everyone's build requirements. So why Yet Another build tool?
Most of the build tools just mentioned were written by programmers and for programmers. The fact that most programmer-friendly utilities do a poor job of fulfilling the needs of non-programmers prompted Greg Wilson to organize the Software Carpentry competition in January 2000. Software Carpentry was an open design contest with the express goal of producing a set of next-generation utilities, including a build tool, that would be accessible not only to programmers but also to computer users such as physical scientists.
The key to this usability would be that all of these utilities, including the build tool, would be written in Python. This provided the catalyst for actually pursuing an idea that had been floating around one of the more intriguing Make alternatives, a Perl utility called Cons. What if the friendlier syntax of Python could be married to the architectural advantages of Cons?
The resulting merged design, at that time named ScCons, won the Software Carpentry build tool competition. CodeSourcery (by then the administrators of the competition) ultimately decided not to fund development of the build tool, but the seed had been planted and the design had taken root.
It helps to know something about Cons. Cons was first released in 1996 by Bob Sidebotham, then an employee of Fore Systems, and it has a number of distinctive features that set it apart from most Make-alikes:
Cons "configuration files" are not Yet Another invented mini-language, but are actually Perl scripts, which means the full power and flexibility of a real scripting language can be applied to build problems.
Cons builds everything from a single process at the top of the source tree, with a global view of the dependencies.
Cons scans files automatically for dependencies such as files specified on #include lines.
Cons decides if a file was out-of-date by using MD5 checksums of the contents of files, not timestamps.
Despite all of these intriguing architectural features, the great strength of Cons—being written in Perl—was also one of its weaknesses, turning away many potential users due to the (real or perceived) steep learning curve of Perl.
Through the ScCons contest entry, SCons is the direct descendant of the Cons architecture, and is currently under active, supported development with a growing body of users. Its first release was 13 December 2001, under the simple and non-restrictive MIT license, and from the outset, the goal of the members of the SCons project has been to deliver a stable, reliable tool that can be used for industrial-strength software builds.
The rest of this paper will give an overview of the SCons design (including its architecture and interface), describe the development methodology used, and discuss future directions for SCons.
| Next >>> | ||
| Architecture |