summaryrefslogtreecommitdiff
path: root/doc/python10/intro.xml
diff options
context:
space:
mode:
authorLuca Falavigna <dktrkranz@debian.org>2010-01-02 20:56:35 +0100
committerLuca Falavigna <dktrkranz@debian.org>2010-01-02 20:56:35 +0100
commit64c458487151933ee0ba093cf4ac69e177d9be37 (patch)
treef6e3755704f53406eea85532e4ffe5d5ef50b7f0 /doc/python10/intro.xml
parent2aec9cc58398cac1376509a7d75edb83b41f984e (diff)
parent72c578fd4b0b4a5a43e18594339ac4ff26c376dc (diff)
Merge commit 'upstream/1.2.0.d20091224'
Diffstat (limited to 'doc/python10/intro.xml')
-rw-r--r--doc/python10/intro.xml212
1 files changed, 212 insertions, 0 deletions
diff --git a/doc/python10/intro.xml b/doc/python10/intro.xml
new file mode 100644
index 0000000..d3057be
--- /dev/null
+++ b/doc/python10/intro.xml
@@ -0,0 +1,212 @@
+<para>
+
+ 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:
+
+</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para>
+
+ 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.
+
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
+ Builds of typical large software systems still take hours, if not
+ days, despite the tremendous advances in CPU and disk speeds over
+ recent years.
+
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
+ &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
+ inherently fragile.
+
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
+ 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.
+
+ </para>
+ </listitem>
+
+</itemizedlist>
+
+<para>
+
+ 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?
+
+</para>
+
+<section>
+ <title>Enter Software Carpentry</title>
+
+ <para>
+
+ 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 <emphasis>users</emphasis>
+ such as physical scientists.
+
+ </para>
+
+ <para>
+
+ 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;?
+
+ </para>
+
+ <para>
+
+ 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.
+
+ </para>
+
+</section>
+
+<section>
+ <title>Cons</title>
+
+ <para>
+
+ 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:
+
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+
+ &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.
+
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
+ &Cons; builds everything from a single process at the top of the
+ source tree, with a global view of the dependencies.
+
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
+ &Cons; scans files automatically for dependencies such as
+ files specified on <literal>#include</literal> lines.
+
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
+ &Cons; decides if a file was out-of-date by using MD5 checksums of
+ the contents of files, not timestamps.
+
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+
+ Despite all of these intriguing architectural features, the great
+ strength of &Cons;&mdash;being written in Perl&mdash;was also one of
+ its weaknesses, turning away many potential users due to the
+ (real or perceived) steep learning curve of Perl.
+
+ </para>
+
+</section>
+
+<section>
+ <title>&SCons;</title>
+
+ <para>
+
+ 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.
+
+ </para>
+
+ <para>
+
+ 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;.
+
+ </para>
+
+</section>