doc/design/goals.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    As a next-generation build tool,
  29    &SCons; should fundamentally
  30    improve on its predecessors.
  31    Rather than simply being driven by trying to
  32    <emphasis>not</emphasis> be like previous tools,
  33    &SCons; aims to satisfy the following goals:
  34
  35  </para>
  36
  37  <variablelist>
  38
  39   <varlistentry>
  40    <term><literal>Practicality</literal></term>
  41    <listitem>
  42     <para>
  43
  44      The &SCons; design emphasizes
  45      an implementable feature set
  46      that lets users get practical, useful work done.
  47      &SCons; is helped in this regard by its roots in &Cons;,
  48      which has had its feature set honed by
  49      several years of input
  50      from a dedicated band of users.
  51
  52     </para>
  53    </listitem>
  54   </varlistentry>
  55
  56   <varlistentry>
  57    <term><literal>Portability</literal></term>
  58    <listitem>
  59     <para>
  60
  61      &SCons; is intended as a portable build tool,
  62      able to handle software construction tasks
  63      on a variety of operating systems.
  64      It should be possible (although not mandatory)
  65      to use &SCons; so that the same configuration file
  66      builds the same software correctly on,
  67      for example, both Linux and Windows NT.
  68      Consequently, &SCons; should hide from users
  69      operating-system-dependent details
  70      such as filename extensions
  71      (for example, <filename>.o</filename>
  72      vs. <filename>.obj</filename>).
  73
  74      <!--
  75      XXX: enable writing portable builds without forcing it
  76      -->
  77
  78      <!--
  79      XXX: still write non-portably for quick-and-dirty
  80      -->
  81
  82     </para>
  83    </listitem>
  84   </varlistentry>
  85
  86   <varlistentry>
  87    <term><literal>Usability</literal></term>
  88    <listitem>
  89     <para>
  90
  91      Novice users should be able to grasp quickly
  92      the rudiments of using &SCons; to build their software.
  93      This extends to installing &SCons;, too.
  94      Installation should be painless,
  95      and the installed &SCons;
  96      should work "out of the box"
  97      to build most software.
  98
  99     </para>
 100
 101     <para>
 102
 103      This goal should be kept in mind during implementation,
 104      when there is always a tendency to try to optimize too early.
 105      Speed is nice, but not as important as clarity
 106      and ease of use.
 107
 108     </para>
 109    </listitem>
 110   </varlistentry>
 111
 112   <varlistentry>
 113    <term><literal>Utility</literal></term>
 114    <listitem>
 115     <para>
 116
 117      &SCons; should also provide a rich enough set of features
 118      to accommodate building more complicated software projects.
 119      However, the features required for
 120      building complicated software projects
 121      should not get in the way of novice users.
 122      (See the previous goal.)
 123      In other words, complexity should be available
 124      when it's needed
 125      but not required to get work done.
 126      Practically, this implies that &SCons;
 127      shouldn't be dumbed down to the point it
 128      excludes complicated software builds.
 129
 130     </para>
 131    </listitem>
 132   </varlistentry>
 133
 134   <varlistentry>
 135    <term><literal>Sharability</literal></term>
 136    <listitem>
 137     <para>
 138
 139      As a key element in balancing the conflicting
 140      needs of <literal>Usability</literal> and <literal>Utility</literal>,
 141      &SCons; should provide mechanisms to
 142      allow &SCons; users to share build rules,
 143      dependency scanners, and other objects and recipes
 144      for constructing software.
 145      A good sharing mechanism should support
 146      the model wherein most developers on a project
 147      use rules and templates
 148      that are created
 149      and maintained by a local integrator or build-master,
 150
 151     </para>
 152    </listitem>
 153   </varlistentry>
 154
 155   <varlistentry>
 156    <term><literal>Extensibility</literal></term>
 157    <listitem>
 158     <para>
 159
 160      &SCons; should provide mechanisms for
 161      easily extending its capabilities,
 162      including building new types of files,
 163      adding new types of dependency scanning,
 164      being able to accomodate dependencies
 165      between objects other than files,
 166      etc.
 167
 168     </para>
 169    </listitem>
 170   </varlistentry>
 171
 172   <varlistentry>
 173    <term><literal>Flexibility</literal></term>
 174    <listitem>
 175     <para>
 176
 177      In addition to providing a useful command-line interface,
 178      &SCons; should provide the right architectural
 179      framework for embedding its dependency management
 180      in other interfaces.
 181      &SCons; would help strengthen other GUIs or IDEs
 182      and the additional requirements of the
 183      other interfaces would help broaden and solidify
 184      the core &SCons; dependency management.
 185
 186     </para>
 187    </listitem>
 188   </varlistentry>
 189
 190  </variablelist>
 191
 192 <section id="sect-fix-make">
 193  <title>Fixing &Make;'s problems</title>
 194
 195  <para>
 196
 197 <!--
 198 To be written.
 199 -->
 200
 201  </para>
 202
 203 </section>
 204
 205 <section id="sect-fix-cons">
 206  <title>Fixing &Cons;'s problems</title>
 207
 208   <para>
 209
 210 <!--
 211 To be written.
 212 -->
 213
 214   </para>
 215
 216 </section>