Merge commit 'upstream/1.2.0.d20091224'

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>