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:
is the set of variables in the user's environment
at the time the user runs SCons.
These variables are available within the
through the Python
See Section 7.1, “Using Values From the External Environment”, below.
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
including the ability to clone a new, customized
construction environment from an existing
See Section 7.2, “Construction Environments”, below.
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
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
which inherit 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.
variable settings that
the user has in force
when executing SCons
are available through the normal Python
This means that you must add an
import os statement
in which you want to use
values from the user's external environment.
More usefully, you can use the
dictionary in your
files to initialize
with values from the user's external environment.
See the next section,
Section 7.2, “Construction Environments”,
for information on how to do this.