doc/design/bground.xml

   1 <!--
   2
   3   Copyright (c) 2001, 2002, 2003 Steven Knight
   4
   5   Permission is hereby granted, free of charge, to any person obtaining
   6   a copy of this software and associated documentation files (the
   7   "Software"), to deal in the Software without restriction, including
   8   without limitation the rights to use, copy, modify, merge, publish,
   9   distribute, sublicense, and/or sell copies of the Software, and to
  10   permit persons to whom the Software is furnished to do so, subject to
  11   the following conditions:
  12
  13   The above copyright notice and this permission notice shall be included
  14   in all copies or substantial portions of the Software.
  15
  16   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
  17   KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
  18   WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  19   NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  20   LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  21   OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  22   WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  23
  24 -->
  25
  26  <para>
  27
  28   Most of the ideas in &SCons; originate with &Cons;, a Perl-based
  29   software construction utility that has been in use by a small but
  30   growing community since its development by Bob Sidebotham at FORE
  31   Systems in 1996.  The &Cons; copyright was transferred in 2000 from
  32   Marconi (who purchased FORE Systems) to the Free Software Foundation.
  33   I've been a principal implementer and maintainer of &Cons; for several
  34   years.
  35
  36  </para>
  37
  38  <para>
  39
  40   &Cons; was originally designed to handle complicated software build
  41   problems (multiple directories, variant builds) while keeping the
  42   input files simple and maintainable. The general philosophy is that
  43   the build tool should ``do the right thing'' with minimal input
  44   from an unsophisticated user, while still providing a rich set of
  45   underlying functionality for more complicated software construction
  46   tasks needed by experts.
  47
  48  </para>
  49
  50  <para>
  51
  52   In 2000, the Software Carpentry sought entries in a contest for a
  53   new, Python-based build tool that would provide an improvement
  54   over Make for physical scientists and other non-programmers
  55   struggling to use their computers more effectively.  Prior to that,
  56   the idea of combining the superior build architecture of &Cons;
  57   with the easier syntax of Python had come up several times on
  58   the <literal>cons-discuss</literal> mailing list.  The Software
  59   Carpentry contest provided the right motivation to spend some
  60   actual time working on a design document.
  61
  62  </para>
  63
  64  <para>
  65
  66   After two rounds of competition, the submitted design, named
  67   <application>ScCons</application>, won the competition.  Software
  68   Carpentry, however, did not immediately fund implementation of the
  69   build tool, instead contracting for additional, more detailed draft(s)
  70   of the design document.  This proved to be not as strong motivation as
  71   actual coding, and after several months of inactivity, I essentially
  72   resigned from the Software Carpentry effort in early 2001 to start
  73   working on the tool independently.
  74
  75  </para>
  76
  77  <para>
  78
  79   After half a year of prototyping some of the important infrastructure,
  80   I accumulated enough code to take the project public at SourceForge,
  81   renaming it &SCons; to distinguish it slightly from the version of the
  82   design that won the Software Carpentry contest while still honoring
  83   its roots there and in the original &Cons; utility.  And also because
  84   it would be a teensy bit easier to type.
  85
  86  </para>