PyScript

This Builder runs python scripts and modules.

First, it will automatically find the “.py” files referred to when
running a module as a script with the ‘-m’ option. For example
the following code will run a module as script and add the appriate files
to the dependencies:

Second, it defaults the command string to “python $SOURCES” and using the “capture”
keyword argument, can automatically append the appropriate strings to capture
the output or error (or both) to the targets:

PyScons (experimental)

This Builder enables running a python script as if it is a scons script.

This is distinct from SConscript which functions like an include. Instead, PyScons spawns a new scons process.
Spawning a new process allows for temporary files to be automatically deleted without triggering a rebuild.

To use this builder, create a .py file with, for example, the following code in a file (my_scons.py):

The temp file be generated if it is required to generate targets, but will be immediately deleted.
This is useful for builders which generate large intermediate files which would should be deleted
without triggering a rebuild. This can be better than passing a list to the Command function for a
few special cases:

PyScons enables parallel execution of a multistep submodule(if you pass the -j option to the spawned scons)

PyScons creates a workflow environment (like Pipeline Pilot) in scons which enables complex tasks to be packaged in scons files for use in other scons files.

PyScons can turn intermediate file deletion on and off with a single flag:

PyScons ignores the “options” parameter when constructing the command’s signature, enabling you to change parameters (e.g. the -j number of procs) without triggering a rebuild.

Unfortunately, dependency tracking does not propagate up from the spawned scons. In this example,
“step1.py” and “step2.py” will not be tracked and changes to them will not trigger a rebuild. There
is a trick around this, add the following two lines to “my_scons.py”:

### step1.py
#DEPENDS step2.py

These two comments illustrate the two ways of explicetely including the dependency on the two
scripts used on the scons file. To help distinguish files which are to be run in this ways
(being called by PyScons), they may be given the extensions “.scons” or “.pyscons” as well.
In this example, this would amount to renaming “my_scons.py” to “my_scons.scons”

PyScanner

This scanner uses the modulefinder module to find all import dependencies
in all sources with a ‘py’ extension. It can take two options in its constructor:

filter_path: a callable object (or None) which takes a path as input and returns true
if this file should be included as a dependency by scons, or false if it should be ignored.
By default, this variable becomes a function which ensures that no system python modules
or modules from site-packages are tracked. To track all files, use “lambda p: True”.

recursive: with a true (default) or false, it enables or disables recursive dependency
tracking.

For example to track all files (including system imports) in a nonrecursive scanner, use
the following install code in your SConstruct: