The experience of configuring any
software build tool to build a large code base
usually, at some point,
involves trying to figure out why
the tool is behaving a certain way,
and how to get it to behave the way you want.
&SCons; is no different.
Why is That Target Being Rebuilt? the &debug-explain; Option
Let's take a simple example of
a misconfigured build
that causes a target to be rebuilt
every time &SCons; is run:
# Intentionally misspell the output file name in the
# command used to create the file:
Command('file.out', 'file.in', 'cp $SOURCE file.oout')
file.in
(Note to Windows users: The POSIX &cp; command
copies the first file named on the command line
to the second file.
In our example, it copies the &file_in; file
to the &file_out; file.)
Now if we run &SCons; multiple on this example,
we see that it re-runs the &cp;
command every time:
scons -Q
scons -Q
scons -Q
In this example,
the underlying cause is obvious:
we've intentionally misspelled the output file name
in the &cp; command,
so the command doesn't actually
build the &file_out; file that we've told &SCons; to expect.
But if the problem weren't obvious,
it would be helpful
to specify the &debug-explain; option
on the command line
to have &SCons; tell us very specifically
why it's decided to rebuild the target:
scons -Q --debug=explain
If this had been a more complicated example
involving a lot of build output,
having &SCons; tell us that
it's trying to rebuild the target file
because it doesn't exist
would be an important clue
that something was wrong with
the command that we invoked to build it.
The &debug-explain; option also comes in handy
to help figure out what input file changed.
Given a simple configuration that builds
a program from three source files,
changing one of the source files
and rebuilding with the &debug-explain;
option shows very specifically
why &SCons; rebuilds the files that it does:
Program('prog', ['file1.c', 'file2.c', 'file3.c'])
file1.c
file2.c
file3.c
scons -Q
edit file2.c
scons -Q --debug=explain
This becomes even more helpful
in identifying when a file is rebuilt
due to a change in an implicit dependency,
such as an incuded .h file.
If the file1.c
and file3.c files
in our example
both included a &hello_h; file,
then changing that included file
and re-running &SCons; with the &debug-explain; option
will pinpoint that it's the change to the included file
that starts the chain of rebuilds:
Program('prog', ['file1.c', 'file2.c', 'file3.c'], CPPPATH='.')
#include <hello.h>
file1.c
file2.c
#include <hello.h>
file3.c
#define string "world"
scons -Q
edit hello.h
scons -Q --debug=explain
What's in That Construction Environment? the &Dump; Method
When you create a construction environment,
&SCons; populates it
with construction variables that are set up
for various compilers, linkers and utilities
that it finds on your system.
Although this is usually helpful and what you want,
it might be frustrating if &SCons;
doesn't set certain variables that you
expect to be sit.
In situations like this,
it's sometimes helpful to use the
construction environment &Dump; method
to print all or some of
the construction variables.
Note that the &Dump; method
returns
the representation of the variables
in the environment
for you to print (or otherwise manipulate):
env = Environment()
print env.Dump()
On a POSIX system with gcc installed,
this might generate:
scons
On a Windows system with Visual C++
the output might look like:
scons
The construction environments in these examples have
actually been restricted to just gcc and Visual C++,
respectively.
In a real-life situation,
the construction environments will
likely contain a great many more variables.
To make it easier to see just what you're
interested in,
the &Dump; method allows you to
specify a specific constrcution variable
that you want to disply.
For example,
it's not unusual to want to verify
the external environment used to execute build commands,
to make sure that the PATH and other
environment variables are set up the way they should be.
You can do this as follows:
env = Environment()
print env.Dump('ENV')
Which might display the following when executed on a POSIX system:
scons
And the following when executed on a Windows system:
scons