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
|
<!--
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>
The &SCons; tool provides an easy-to-use, feature-rich interface
for constructing software. Architecturally, &SCons; separates
its dependency analysis and external object management into an
interface-independent Build Engine that could be embedded in any
software system that can run Python.
</para>
<para>
At the command line, &SCons; presents an easily-grasped tool
where configuration files are Python scripts, reducing the need
to learn new build-tool syntax. Inexperienced users can use
intelligent methods that ``do the right thing'' to build software
with a minimum of fuss. Sophisticated users can use a rich set
of underlying features for finer control of the build process,
including mechanisms for easily extending the build process to new
file types.
</para>
<para>
Dependencies are tracked using digital signatures,
which provide more robust dependency analysis than file time
stamps. Implicit dependencies are determined automatically by
scanning the contents of source files, avoiding the need for
laborious and fragile maintenance of static lists of dependencies in
configuration files.
</para>
<para>
The &SCons; tool supports use of files from one or more central code
repositories, a mechanism for caching derived files, and parallel
builds. The tool also includes a framework for sharing build
environments, which allows system administrators or integrators to
define appropriate build parameters for use by other users.
</para>
<section id="sect-document">
<title>About This Document</title>
<para>
This document is an ongoing work-in-progress to write down the ideas
and tradeoffs that have gone, and will go into, the &SCons; design.
As such, this is intended primarily for use by developers and others
working on &SCons;, although it is also intended to serve as a
detailed overview of &SCons; for other interested parties. It will
be continually updated and evolve, and will likely overlap with other
documentation produced by the project. Sections of this document
that deal with syntax, for example, may move or be copied into a user
guide or reference manual.
</para>
<para>
So please don't assume that everything mentioned here has been
decided and carved in stone. If you have ideas for improvements, or
questions about things that don't seem to make any sense, please help
improve the design by speaking up about them.
</para>
<REMARK>
Sections marked like this
(prefixed with <literal>RATIONALE:</literal> in the HTML,
surrounded by <literal>BEGIN RATIONALE:</literal>
and <literal>END RATIONALE:</literal>
in the printed documentatio)
are DocBook REMARKs,
comments about the document
rather than actual document.
I've used these to mark sections that need work,
but also to cite some open design issues.
If you have input on any of these marked issues,
I'm especially eager to hear it.
</REMARK>
</section>
|