<!DOCTYPE sconsdoc [
<!ENTITY % scons SYSTEM "../scons.mod">
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
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
&Make; maintains static definitions of dependencies in its
&Makefiles;. Much effort has been put into
utilities (<application>mkdepend</application>, <application>gcc
-M</application>) and schemes (<filename>Makefile.d</filename>
files) to try to keep &Makefile; dependencies up-to-date,
but these only confirm that &Make;'s static dependencies are
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?
<title>Enter Software Carpentry</title>
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
not only to
but also to computer <emphasis>users</emphasis>
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 <emphasis>Perl
scripts</emphasis>, 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 <literal>#include</literal> 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;.