summaryrefslogtreecommitdiff
path: root/doc/design/goals.xml
diff options
context:
space:
mode:
Diffstat (limited to 'doc/design/goals.xml')
-rw-r--r--doc/design/goals.xml216
1 files changed, 216 insertions, 0 deletions
diff --git a/doc/design/goals.xml b/doc/design/goals.xml
new file mode 100644
index 0000000..2a7b69b
--- /dev/null
+++ b/doc/design/goals.xml
@@ -0,0 +1,216 @@
+<!--
+
+ Copyright (c) 2001, 2002, 2003 Steven Knight
+
+ Permission is hereby granted, free of charge, to any person obtaining
+ a copy of this software and associated documentation files (the
+ "Software"), to deal in the Software without restriction, including
+ without limitation the rights to use, copy, modify, merge, publish,
+ distribute, sublicense, and/or sell copies of the Software, and to
+ permit persons to whom the Software is furnished to do so, subject to
+ the following conditions:
+
+ The above copyright notice and this permission notice shall be included
+ in all copies or substantial portions of the Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
+ KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
+ WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+-->
+
+ <para>
+
+ As a next-generation build tool,
+ &SCons should fundamentally
+ improve on its predecessors.
+ Rather than simply being driven by trying to
+ <emphasis>not</emphasis> be like previous tools,
+ &SCons; aims to satisfy the following goals:
+
+ </para>
+
+ <variablelist>
+
+ <varlistentry>
+ <term><literal>Practicality</literal></term>
+ <listitem>
+ <para>
+
+ The &SCons; design emphasizes
+ an implementable feature set
+ that lets users get practical, useful work done.
+ &SCons; is helped in this regard by its roots in &Cons;,
+ which has had its feature set honed by
+ several years of input
+ from a dedicated band of users.
+
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>Portability</literal></term>
+ <listitem>
+ <para>
+
+ &SCons; is intended as a portable build tool,
+ able to handle software construction tasks
+ on a variety of operating systems.
+ It should be possible (although not mandatory)
+ to use &SCons; so that the same configuration file
+ builds the same software correctly on,
+ for example, both Linux and Windows NT.
+ Consequently, &SCons; should hide from users
+ operating-system-dependent details
+ such as filename extensions
+ (for example, <filename>.o</filename>
+ vs. <filename>.obj</filename>).
+
+ <!--
+ XXX: enable writing portable builds without forcing it
+ -->
+
+ <!--
+ XXX: still write non-portably for quick-and-dirty
+ -->
+
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>Usability</literal></term>
+ <listitem>
+ <para>
+
+ Novice users should be able to grasp quickly
+ the rudiments of using &SCons; to build their software.
+ This extends to installing &SCons;, too.
+ Installation should be painless,
+ and the installed &SCons;
+ should work "out of the box"
+ to build most software.
+
+ </para>
+
+ <para>
+
+ This goal should be kept in mind during implementation,
+ when there is always a tendency to try to optimize too early.
+ Speed is nice, but not as important as clarity
+ and ease of use.
+
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>Utility</literal></term>
+ <listitem>
+ <para>
+
+ &SCons; should also provide a rich enough set of features
+ to accommodate building more complicated software projects.
+ However, the features required for
+ building complicated software projects
+ should not get in the way of novice users.
+ (See the previous goal.)
+ In other words, complexity should be available
+ when it's needed
+ but not required to get work done.
+ Practically, this implies that &SCons;
+ shouldn't be dumbed down to the point it
+ excludes complicated software builds.
+
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>Sharability</literal></term>
+ <listitem>
+ <para>
+
+ As a key element in balancing the conflicting
+ needs of <literal>Usability</literal> and <literal>Utility</literal>,
+ &SCons; should provide mechanisms to
+ allow &SCons; users to share build rules,
+ dependency scanners, and other objects and recipes
+ for constructing software.
+ A good sharing mechanism should support
+ the model wherein most developers on a project
+ use rules and templates
+ that are created
+ and maintained by a local integrator or build-master,
+
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>Extensibility</literal></term>
+ <listitem>
+ <para>
+
+ &SCons; should provide mechanisms for
+ easily extending its capabilities,
+ including building new types of files,
+ adding new types of dependency scanning,
+ being able to accomodate dependencies
+ between objects other than files,
+ etc.
+
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>Flexibility</literal></term>
+ <listitem>
+ <para>
+
+ In addition to providing a useful command-line interface,
+ &SCons; should provide the right architectural
+ framework for embedding its dependency management
+ in other interfaces.
+ &SCons; would help strengthen other GUIs or IDEs
+ and the additional requirements of the
+ other interfaces would help broaden and solidify
+ the core &SCons; dependency management.
+
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+<section id="sect-fix-make">
+ <title>Fixing &Make;'s problems</title>
+
+ <para>
+
+<!--
+To be written.
+-->
+
+ </para>
+
+</section>
+
+<section id="sect-fix-cons">
+ <title>Fixing &Cons;'s problems</title>
+
+ <para>
+
+<!--
+To be written.
+-->
+
+ </para>
+
+</section>