doc/design/goals.xml

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