Initial installation of a new utility provides the first, lasting impression of how well the software is likely to perform. From the start, &SCons; has made clean installation a priority.

Distributing an application like &SCons; that depends on a package normally found in a library poses a problem. If the &scons; script and the &SCons; Build Engine are installed separately, it could be easy to introduce a version mismatch between the Build Engine installed in /usr/lib/python*/site-packages and the &scons; script installed in /usr/bin. Such a mismatch could possible mean exceptions that prevent builds, or even worse, silently unreliable builds. To reduce the possibility of a version mismatch, the &scons; script looks first for its imported modules in /usr/lib/scons-{version}/, then in /usr/lib/scons/, and then in the normal &PYTHONPATH; locations, including /usr/lib/python*/site-packages). Searching in a version-specific library directory first makes it convenient to install and use multiple side-by-side versions of &SCons;, which is sometimes important when verifying that a new version does not introduce any errors into the local build process. Searching next in an &SCons;-specific library directory makes it convenient for other software to find the &SCons; Build Engine without having to worry about installing separate copies for multiple versions of Python.

&SCons; is currently distributed in the following packages: scons-version.tar.gz The traditional .tar.gz file, installable by running setup.py. scons-version.noarch.rpm An RPM file for typical installation. scons-version_all.deb A Debian package. scons-version.win32.exe A Windows installer. scons-version.src.rpm A source RPM file. scons-src-version.tar.gz A tarball of the &SCons; source tree, including the full set of regression tests. Like other software written in Python, &SCons; benefits greatly from the tremendous effort put into the distutils by Greg Ward and others. These take care of 90% of the work by making it almost trivial to generate the appropriate RPM files, Debian packages, and Windows installer.

As part of the installation process, &SCons; runs a set of scripts that look for popular compilers and other tools and set up appropriate default &Builder; objects for the tools found. These &Builder; objects are then used to initialize the default &consenv; values.

Additionally, &SCons; comes with a stock set of &Scanner; objects for the various file types that it supports out of the box. Any unusal &Scanner; objects required for a specific tool will be detected at installation time and associated with the appropriate &Builder; object for the tool.