doc/python10/intro.xml

   1 <para>
   2
   3   More than twenty years after its creation, the classic UNIX &Make;
   4   utility and its descendants are still the dominant way in which
   5   software is built. &Make; has maintained this position despite the
   6   fact that the intervening years have revealed many
   7   shortcomings of the &Make; model for building software:
   8
   9 </para>
  10
  11 <itemizedlist>
  12
  13   <listitem>
  14     <para>
  15
  16       The use of timestamps to decide when a file has been updated is
  17       imprecise and prone to error, especially across distributed file
  18       systems such as NFS.
  19
  20     </para>
  21   </listitem>
  22
  23   <listitem>
  24     <para>
  25
  26       Builds of typical large software systems still take hours, if not
  27       days, despite the tremendous advances in CPU and disk speeds over
  28       recent years.
  29
  30     </para>
  31   </listitem>
  32
  33   <listitem>
  34     <para>
  35
  36       &Make; maintains static definitions of dependencies in its
  37       &Makefiles;. Much effort has been put into
  38       utilities (<application>mkdepend</application>, <application>gcc
  39       -M</application>) and schemes (<filename>Makefile.d</filename>
  40       files) to try to keep &Makefile; dependencies up-to-date,
  41       but these only confirm that &Make;'s static dependencies are
  42       inherently fragile.
  43
  44     </para>
  45   </listitem>
  46
  47   <listitem>
  48     <para>
  49
  50       The standard recursive use of &Make; for build hierarchies leads
  51       to incomplete dependency graphs, which must be overcome by
  52       manually changing the order in which directories are built, or
  53       through the use of multiple build passes.
  54
  55     </para>
  56   </listitem>
  57
  58 </itemizedlist>
  59
  60 <para>
  61
  62   One need only look at the plethora of helper and wrapper utilities
  63   (automake, easymake, imake, jmake, makeLib, maketool, mkmed, shake,
  64   SMake, TMAKE) and complete alternatives to &Make; (Ant, bake, bau,
  65   bras, Cake, Cons, Cook, Jam, jmk, jus, makeme, mash, MK, nmake, Odin,
  66   VMake) that have been created over the years to realize that vanilla
  67   &Make; is not satisfying everyone's build requirements. So why Yet
  68   Another build tool?
  69
  70 </para>
  71
  72 <section>
  73   <title>Enter Software Carpentry</title>
  74
  75   <para>
  76
  77     Most of the build tools just mentioned
  78     were written by programmers and for
  79     programmers. The fact that most programmer-friendly
  80     utilities do a poor job of fulfilling the needs
  81     of non-programmers prompted Greg Wilson to
  82     organize the Software Carpentry competition in January 2000.
  83     Software Carpentry was an
  84     open design contest with the express goal of producing a set of
  85     next-generation utilities, including a build tool, that would be
  86     accessible
  87     not only to
  88     programmers
  89     but also to computer <emphasis>users</emphasis>
  90     such as physical scientists.
  91
  92   </para>
  93
  94   <para>
  95
  96     The key to this usability would be that all of
  97     these utilities, including the build tool, would be
  98     written in Python.
  99     This provided the catalyst for actually
 100     pursuing an idea
 101     that had been floating around one of the more
 102     intriguing &Make; alternatives,
 103     a Perl utility called &Cons;.
 104     What if the friendlier syntax of Python
 105     could be married to the
 106     architectural advantages of &Cons;?
 107
 108   </para>
 109
 110   <para>
 111
 112     The resulting merged design, at that time named &ScCons;,
 113     won the Software Carpentry build tool competition. CodeSourcery (by
 114     then the administrators of the competition) ultimately decided not to
 115     fund development of the build tool, but the seed had been planted and the
 116     design had taken root.
 117
 118   </para>
 119
 120 </section>
 121
 122 <section>
 123   <title>Cons</title>
 124
 125   <para>
 126
 127     It helps to know something about &Cons;.
 128     &Cons; was first released in 1996 by Bob Sidebotham,
 129     then an employee of Fore Systems,
 130     and it has a number of
 131     distinctive features that set it apart from most &Make;-alikes:
 132
 133   </para>
 134
 135   <itemizedlist>
 136
 137     <listitem>
 138       <para>
 139
 140         &Cons; "configuration files" are not Yet Another
 141         invented mini-language, but are actually <emphasis>Perl
 142         scripts</emphasis>, which means the full power and flexibility of
 143         a real scripting language can be applied to build problems.
 144
 145       </para>
 146     </listitem>
 147
 148     <listitem>
 149       <para>
 150
 151         &Cons; builds everything from a single process at the top of the
 152         source tree, with a global view of the dependencies.
 153
 154       </para>
 155     </listitem>
 156
 157     <listitem>
 158       <para>
 159
 160         &Cons; scans files automatically for dependencies such as
 161         files specified on <literal>#include</literal> lines.
 162
 163       </para>
 164     </listitem>
 165
 166     <listitem>
 167       <para>
 168
 169         &Cons; decides if a file was out-of-date by using MD5 checksums of
 170         the contents of files, not timestamps.
 171
 172       </para>
 173     </listitem>
 174
 175   </itemizedlist>
 176
 177   <para>
 178
 179     Despite all of these intriguing architectural features, the great
 180     strength of &Cons;&mdash;being written in Perl&mdash;was also one of
 181     its weaknesses, turning away many potential users due to the
 182     (real or perceived) steep learning curve of Perl.
 183
 184   </para>
 185
 186 </section>
 187
 188 <section>
 189   <title>&SCons;</title>
 190
 191   <para>
 192
 193     Through the &ScCons; contest entry,
 194     &SCons; is the direct descendant of the &Cons; architecture,
 195     and is currently
 196     under active, supported development with a growing body of
 197     users. Its first release was 13 December 2001, under the simple and
 198     non-restrictive MIT license, and from the outset, the goal of the
 199     members of the &SCons; project has been to deliver a stable, reliable
 200     tool that can be used for industrial-strength software builds.
 201
 202   </para>
 203
 204   <para>
 205
 206     The rest of this paper will give an overview of the &SCons; design
 207     (including its architecture and interface), describe the development
 208     methodology used, and discuss future directions for &SCons;.
 209
 210   </para>
 211
 212 </section>