3 Initial installation of a new utility provides the first, lasting
4 impression of how well the software is likely to perform. From the
5 start, &SCons; has made clean installation a priority.
10 <title>Version Control</title>
14 Distributing an application like &SCons; that depends
15 on a package normally found in a library poses a
16 problem. If the &scons; script and the &SCons; Build Engine
17 are installed separately, it could be easy
18 to introduce a version mismatch between the Build Engine
20 <filename>/usr/lib/python*/site-packages</filename>
21 and the &scons; script installed in
22 <filename>/usr/bin</filename>.
24 could possible mean exceptions that prevent builds, or even worse,
25 silently unreliable builds.
31 To reduce the possibility of a version mismatch,
32 the &scons; script looks first for its
33 imported modules in <filename>/usr/lib/scons-{version}/</filename>,
34 then in <filename>/usr/lib/scons/</filename>,
35 and then in the normal &PYTHONPATH; locations,
36 including <filename>/usr/lib/python*/site-packages</filename>).
37 Searching in a version-specific library directory first
38 makes it convenient to install and use multiple
39 side-by-side versions of &SCons;,
40 which is sometimes important
41 when verifying that a new version does not introduce any
42 errors into the local build process.
43 Searching next in an &SCons;-specific library directory
44 makes it convenient for other software to find
45 the &SCons; Build Engine without having to worry about
46 installing separate copies for
47 multiple versions of Python.
54 <title>Packages</title>
58 &SCons; is currently distributed in the following packages:
69 <literal>scons-</literal><emphasis>version</emphasis><literal>.tar.gz</literal>
73 The traditional <literal>.tar.gz</literal> file,
74 installable by running <filename>setup.py</filename>.
81 <literal>scons-</literal><emphasis>version</emphasis><literal>.noarch.rpm</literal>
85 An RPM file for typical installation.
92 <literal>scons-</literal><emphasis>version</emphasis><literal>_all.deb</literal>
103 <literal>scons-</literal><emphasis>version</emphasis><literal>.win32.exe</literal>
114 <literal>scons-</literal><emphasis>version</emphasis><literal>.src.rpm</literal>
125 <literal>scons-src-</literal><emphasis>version</emphasis><literal>.tar.gz</literal>
129 A tarball of the &SCons; source tree,
130 including the full set of regression tests.
141 Like other software written in Python, &SCons; benefits greatly from
142 the tremendous effort put into the <literal>distutils</literal> by
143 Greg Ward and others. These take care of 90% of the work by making
144 it almost trivial to generate the appropriate RPM files, Debian
145 packages, and Windows installer.
152 <title>Default Builder Objects</title>
156 As part of the installation process, &SCons; runs a set of scripts
157 that look for popular compilers and other tools and set up
158 appropriate default &Builder; objects for the tools found. These
159 &Builder; objects are then used to initialize the default &consenv;
167 <title>Default Scanner Objects</title>
171 Additionally, &SCons; comes with a stock set of &Scanner; objects
172 for the various file types that it supports out of the box. Any
173 unusal &Scanner; objects required for a specific tool will be
174 detected at installation time and associated with the appropriate
175 &Builder; object for the tool.