summaryrefslogtreecommitdiffstats
path: root/doc/design/goals.xml
blob: f2e6b7c7a96b0106373a6549f1c5aa6d9ddf4cb6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
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>