is a collection of values that
can affect how a program executes.
SCons distinguishes between three
different types of environments
that can affect the behavior of SCons itself
(subject to the configuration in the
as well as the compilers and other tools it executes:
The External Environment is the set of variables in the user's environment at the time the user runs SCons. These variables are not automatically part of an SCons build but are available to be examined if needed. See Section 7.1, “Using Values From the External Environment”, below.
A Construction Environment
is a distinct object created within
SConscript file and
which contains values that
affect how SCons decides
what action to use to build a target,
and even to define which targets
should be built from which sources.
One of the most powerful features of SCons
is the ability to create multiple construction environments,
including the ability to clone a new, customized
construction environment from an existing construction environment.
See Section 7.2, “Construction Environments”, below.
An Execution Environment is the values that SCons sets when executing an external command (such as a compiler or linker) to build one or more targets. Note that this is not the same as the external environment (see above). See Section 7.3, “Controlling the Execution Environment for Issued Commands”, below.
Unlike Make, SCons does not automatically copy or import values between different environments (with the exception of explicit clones of construction environments, which inherit the values from their parent). This is a deliberate design choice to make sure that builds are, by default, repeatable regardless of the values in the user's external environment. This avoids a whole class of problems with builds where a developer's local build works because a custom variable setting causes a different compiler or build option to be used, but the checked-in change breaks the official build because it uses different environment variable settings.
Note that the
SConscript writer can
easily arrange for variables to be
copied or imported between environments,
and this is often very useful
(or even downright necessary)
to make it easy for developers
to customize the build in appropriate ways.
The point is not
that copying variables between different environments
is evil and must always be avoided.
Instead, it should be up to the
implementer of the build system
to make conscious choices
about how and when to import
a variable from one environment to another,
making informed decisions about
striking the right balance
between making the build
repeatable on the one hand
and convenient to use on the other.
The external environment
variable settings that
the user has in force
when executing SCons
are available in the Python
That syntax means the
attribute of the
In Python, to access the contents of a module you must first
import it - so you would include the
import os statement
in which you want to use
values from the user's external environment.
import os print("Shell is", os.environ['SHELL'])
More usefully, you can use the
dictionary in your
files to initialize construction environments
with values from the user's external environment.
Read on to the next section for information on how to do this.