doc/python10/intro.xml

   1 <?xml version='1.0'?>
   2 <!DOCTYPE sconsdoc [
   3     <!ENTITY % scons SYSTEM "../scons.mod">
   4     %scons;
   5 ]>
   6
   7 <section id="sect-intro"
   8          xmlns="http://www.scons.org/dbxsd/v1.0"
   9          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  10          xsi:schemaLocation="http://www.scons.org/dbxsd/v1.0 http://www.scons.org/dbxsd/v1.0/scons.xsd">
  11 <title>Introduction</title>
  12
  13 <!--
  14
  15   __COPYRIGHT__
  16
  17   Permission is hereby granted, free of charge, to any person obtaining
  18   a copy of this software and associated documentation files (the
  19   "Software"), to deal in the Software without restriction, including
  20   without limitation the rights to use, copy, modify, merge, publish,
  21   distribute, sublicense, and/or sell copies of the Software, and to
  22   permit persons to whom the Software is furnished to do so, subject to
  23   the following conditions:
  24
  25   The above copyright notice and this permission notice shall be included
  26   in all copies or substantial portions of the Software.
  27
  28   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
  29   KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
  30   WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  31   NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  32   LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  33   OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  34   WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  35
  36 -->
  37
  38 <para>
  39
  40   More than twenty years after its creation, the classic UNIX &Make;
  41   utility and its descendants are still the dominant way in which
  42   software is built. &Make; has maintained this position despite the
  43   fact that the intervening years have revealed many
  44   shortcomings of the &Make; model for building software:
  45
  46 </para>
  47
  48 <itemizedlist>
  49
  50   <listitem>
  51     <para>
  52
  53       The use of timestamps to decide when a file has been updated is
  54       imprecise and prone to error, especially across distributed file
  55       systems such as NFS.
  56
  57     </para>
  58   </listitem>
  59
  60   <listitem>
  61     <para>
  62
  63       Builds of typical large software systems still take hours, if not
  64       days, despite the tremendous advances in CPU and disk speeds over
  65       recent years.
  66
  67     </para>
  68   </listitem>
  69
  70   <listitem>
  71     <para>
  72
  73       &Make; maintains static definitions of dependencies in its
  74       &Makefiles;. Much effort has been put into
  75       utilities (<application>mkdepend</application>, <application>gcc
  76       -M</application>) and schemes (<filename>Makefile.d</filename>
  77       files) to try to keep &Makefile; dependencies up-to-date,
  78       but these only confirm that &Make;'s static dependencies are
  79       inherently fragile.
  80
  81     </para>
  82   </listitem>
  83
  84   <listitem>
  85     <para>
  86
  87       The standard recursive use of &Make; for build hierarchies leads
  88       to incomplete dependency graphs, which must be overcome by
  89       manually changing the order in which directories are built, or
  90       through the use of multiple build passes.
  91
  92     </para>
  93   </listitem>
  94
  95 </itemizedlist>
  96
  97 <para>
  98
  99   One need only look at the plethora of helper and wrapper utilities
 100   (automake, easymake, imake, jmake, makeLib, maketool, mkmed, shake,
 101   SMake, TMAKE) and complete alternatives to &Make; (Ant, bake, bau,
 102   bras, Cake, Cons, Cook, Jam, jmk, jus, makeme, mash, MK, nmake, Odin,
 103   VMake) that have been created over the years to realize that vanilla
 104   &Make; is not satisfying everyone's build requirements. So why Yet
 105   Another build tool?
 106
 107 </para>
 108
 109 <section>
 110   <title>Enter Software Carpentry</title>
 111
 112   <para>
 113
 114     Most of the build tools just mentioned
 115     were written by programmers and for
 116     programmers. The fact that most programmer-friendly
 117     utilities do a poor job of fulfilling the needs
 118     of non-programmers prompted Greg Wilson to
 119     organize the Software Carpentry competition in January 2000.
 120     Software Carpentry was an
 121     open design contest with the express goal of producing a set of
 122     next-generation utilities, including a build tool, that would be
 123     accessible
 124     not only to
 125     programmers
 126     but also to computer <emphasis>users</emphasis>
 127     such as physical scientists.
 128
 129   </para>
 130
 131   <para>
 132
 133     The key to this usability would be that all of
 134     these utilities, including the build tool, would be
 135     written in Python.
 136     This provided the catalyst for actually
 137     pursuing an idea
 138     that had been floating around one of the more
 139     intriguing &Make; alternatives,
 140     a Perl utility called &Cons;.
 141     What if the friendlier syntax of Python
 142     could be married to the
 143     architectural advantages of &Cons;?
 144
 145   </para>
 146
 147   <para>
 148
 149     The resulting merged design, at that time named &ScCons;,
 150     won the Software Carpentry build tool competition. CodeSourcery (by
 151     then the administrators of the competition) ultimately decided not to
 152     fund development of the build tool, but the seed had been planted and the
 153     design had taken root.
 154
 155   </para>
 156
 157 </section>
 158
 159 <section>
 160   <title>Cons</title>
 161
 162   <para>
 163
 164     It helps to know something about &Cons;.
 165     &Cons; was first released in 1996 by Bob Sidebotham,
 166     then an employee of Fore Systems,
 167     and it has a number of
 168     distinctive features that set it apart from most &Make;-alikes:
 169
 170   </para>
 171
 172   <itemizedlist>
 173
 174     <listitem>
 175       <para>
 176
 177         &Cons; "configuration files" are not Yet Another
 178         invented mini-language, but are actually <emphasis>Perl
 179         scripts</emphasis>, which means the full power and flexibility of
 180         a real scripting language can be applied to build problems.
 181
 182       </para>
 183     </listitem>
 184
 185     <listitem>
 186       <para>
 187
 188         &Cons; builds everything from a single process at the top of the
 189         source tree, with a global view of the dependencies.
 190
 191       </para>
 192     </listitem>
 193
 194     <listitem>
 195       <para>
 196
 197         &Cons; scans files automatically for dependencies such as
 198         files specified on <literal>#include</literal> lines.
 199
 200       </para>
 201     </listitem>
 202
 203     <listitem>
 204       <para>
 205
 206         &Cons; decides if a file was out-of-date by using MD5 checksums of
 207         the contents of files, not timestamps.
 208
 209       </para>
 210     </listitem>
 211
 212   </itemizedlist>
 213
 214   <para>
 215
 216     Despite all of these intriguing architectural features, the great
 217     strength of &Cons;&mdash;being written in Perl&mdash;was also one of
 218     its weaknesses, turning away many potential users due to the
 219     (real or perceived) steep learning curve of Perl.
 220
 221   </para>
 222
 223 </section>
 224
 225 <section>
 226   <title>&SCons;</title>
 227
 228   <para>
 229
 230     Through the &ScCons; contest entry,
 231     &SCons; is the direct descendant of the &Cons; architecture,
 232     and is currently
 233     under active, supported development with a growing body of
 234     users. Its first release was 13 December 2001, under the simple and
 235     non-restrictive MIT license, and from the outset, the goal of the
 236     members of the &SCons; project has been to deliver a stable, reliable
 237     tool that can be used for industrial-strength software builds.
 238
 239   </para>
 240
 241   <para>
 242
 243     The rest of this paper will give an overview of the &SCons; design
 244     (including its architecture and interface), describe the development
 245     methodology used, and discuss future directions for &SCons;.
 246
 247   </para>
 248
 249 </section>
 250
 251 </section>