3 Copyright (c) 2001, 2002, 2003 Steven Knight
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:
13 The above copyright notice and this permission notice shall be included
14 in all copies or substantial portions of the Software.
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.
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:
40 <term><literal>Practicality</literal></term>
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.
57 <term><literal>Portability</literal></term>
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>).
75 XXX: enable writing portable builds without forcing it
79 XXX: still write non-portably for quick-and-dirty
87 <term><literal>Usability</literal></term>
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.
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
113 <term><literal>Utility</literal></term>
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
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.
135 <term><literal>Sharability</literal></term>
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
149 and maintained by a local integrator or build-master,
156 <term><literal>Extensibility</literal></term>
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,
173 <term><literal>Flexibility</literal></term>
177 In addition to providing a useful command-line interface,
178 &SCons; should provide the right architectural
179 framework for embedding its dependency management
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.
192 <section id="sect-fix-make">
193 <title>Fixing &Make;'s problems</title>
205 <section id="sect-fix-cons">
206 <title>Fixing &Cons;'s problems</title>