[Scons-dev] SCons 2.4.0 Released

William Blevins wblevins001 at gmail.com
Mon Sep 21 20:06:00 EDT 2015


Never mind.  I am apparently illiterate. I think I need more rest or
something.

Thanks for the hard work!

On Tue, Sep 22, 2015 at 1:02 AM, William Blevins <wblevins001 at gmail.com>
wrote:

> Looks like some of the docs refer to 2.3.6 rather than 2.4.0.  I wouldn't
> release over it, but it might be something to fix for the next release(s).
>
> Can we do an announcement for CL support?
>
> V/R,
> William
>
> On Mon, Sep 21, 2015 at 7:18 PM, Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>>
>>
>>                    SCons - a software construction tool
>>
>>                               Release Notes
>>
>>
>> This is SCons, a tool for building software (and other files).  SCons is
>> implemented in Python, and its "configuration files" are actually Python
>> scripts, allowing you to use the full power of a real scripting language
>> to solve build problems.  You do not, however, need to know Python to
>> use SCons effectively.
>>
>> Please go to http://www.scons.org/download.php to get the latest
>> production
>> release of SCons.
>>
>> So that everyone using SCons can help each other learn how to use it more
>> effectively, please go to http://scons.org/lists.php#users to sign up for
>> the scons-users mailing list.
>>
>> ==============IMPORTANT NOTICE===========
>>
>> As has been pre-announced in SCons's mailing lists:
>>
>> * https://pairlist4.pair.net/pipermail/scons-users/2014-July/002734.html
>> ,
>> *
>> https://pairlist2.pair.net/pipermail/scons-dev/2014-December/002107.html
>> *
>> https://pairlist4.pair.net/pipermail/scons-users/2015-February/003454.html
>>
>> We're planning to switch the Node class to using "slots" in the core
>> sources,
>> mainly to reduce memory consumption by up to 35% in large build projects.
>>
>> This feature has been tested extensively and we don't expect any problems
>> for you.
>> However as with all major changes it would be wise to test V2.4.0 when it
>> is
>> released. Especially if you are directly using the Node class.
>>
>> =================================================================
>>
>>
>> RELEASE 2.4.0 - Mon, 21 Sep 2015 09:07:51 -0700
>>
>>   Please consult the RELEASE.txt file for a summary of changes since the
>> last
>>   release and consult the CHANGES.txt file for complete a list of changes
>>   since last release.  This announcement highlights only the important
>>   changes.
>>
>>   Please note the following important changes since release 2.3.6:
>>     - Switch several core classes to use "slots" to reduce memory
>>       usage. (PR #2180, #2178, #2198)
>>
>>   Please note the following important changes since release 2.3.5:
>>     - Support for Visual Studio 2015
>>
>>   Please note the following important changes since release 2.3.4:
>>     - Documentation fixes for libraries.xml and
>>       builders-writing.xml (#2989 and #2990)
>>     - Extended docs for InstallVersionedLib/SharedLibrary,
>>       and added SKIP_WIN_PACKAGES argument to build script
>>       bootstrap.py (PR #230, #3002).
>>     - Fixed symlink support (PR #227, #2395).
>>     - Updated debug-count test case (PR #229).
>>     - Fixed incomplete LIBS flattening and substitution in
>>       Program scanner(PR #205, #2954).
>>     - Added new method rentry_exists_on_disk to Node.FS (PR #193).
>>     - Fixed several D tests under the different OS.
>>     - Add support for f08 file extensions for Fortran 2008 code.
>>     - Show --config choices if no argument is specified (PR #202).
>>     - Fixed build crash when XML toolchain isn't installed, and
>>       activated compression for ZIP archives.
>>     - Fix for VersionedSharedLibrary under 'sunos' platform.
>>     - Fixed dll link with precompiled headers on MSVC 2012
>>     - Added an 'exclude' parameter to Glob()
>>     - Support for multiple cmdargs (one per variant) in VS project files.
>>     - Various improvements for TempFileMunge class.
>>     - Added an implementation for Visual Studio users files (PR #209).
>>     - Added support for the 'PlatformToolset' tag in VS project files
>> (#2978).
>>     - Added support for '-isystem' to ParseFlags.
>>
>>
>>   Please note the following important changes since release 2.3.3:
>>
>>     -- Fix for EnsureSConsVersion regression in 2.3.3.
>>
>>     -- Fix for interactive mode with Configure contexts
>>
>>   Please note the following important changes since release 2.3.2:
>>
>>     -- On Windows, .def files did not work as sources to shared
>>        libraries or executables, due to a regression which is
>>        corrected in 2.3.3.
>>
>>   Please note the following important changes since release 2.3.0:
>>
>>     -- BitKeeper, CVS, Perforce, RCS, SCCS are deprecated from the
>>        default toolset and will be removed from the default toolset
>>        in future SCons versions to speed up SCons initialization.
>>        The tools themselves continue to be supported.
>>
>>     -- Support for Visual Studio 12.0Exp and 2013
>>
>>     -- Revamp of D language support, focusing on D v2.
>>        D v1 is now deprecated.
>>
>>     -- Fixed NoClean() for multi-target builders.
>>
>>     -- RPM and m4 are no longer in the default toolset on Windows.
>>        Should improve startup speed.
>>
>>     -- TeX fixes: -synctex=1 and cleaning auxiliary files.
>>
>>     -- Fixes to the Docbook tool.
>>
>>   Please note the following important changes since release 2.3.0:
>>
>>     -- Fix failure to relink when LINKCOM or libs change, introduced in
>>        2.3.0.
>>
>>     -- Fix MSVC defaulting TARGET_ARCH to HOST_ARCH and other MSVC
>>        issues.
>>
>>     -- Reduced memory consumption in large builds, which should speed
>>        them up as well.
>>
>>     -- Add new cyglink linker for use with cygwin.
>>
>>     -- Fix leaking file handles to subprocesses
>>
>>     -- Support read-only cache (--cache-readonly)
>>
>>     -- Add Pseudo command to mark targets that shouldn't exist after
>> building
>>
>>   Please note the following important changes since release 2.2.0:
>>
>>     -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.7 IS NOW DEPRECATED
>>
>>        ***IMPORTANT***: This release is the last version of SCons to
>> support
>>        Python versions older than 2.7.  This release will warn if you are
>>        running on Python 2.6 or older; future releases will probably not
>>        work at all, as we are moving toward supporting Python 3.
>>        Use --warn=no-python-version to suppress the warning if needed.
>>
>>     -- A lot of python pre-2.4 compatibility code was removed
>>        in this release.  2.4 is the official floor for SCons,
>>        but this release will likely enforce it more rigidly.
>>
>>     -- Spawning subprocesses on Windows should now be more reliable with
>> -jN
>>
>>     -- MSVC10 and MSVC11 support improved, and fixed MSVS11 solution
>> generation.
>>
>>     -- Various TeX/LaTeX builder improvements
>>
>>     -- Support for versioned shared libs on Linux and Mac, via
>>        SHLIBVERSION and InstallVersionedLib.
>>
>>     -- WiX builder updates
>>
>>   Please note the following important changes since release 2.1.0:
>>
>>     --  New gettext toolset for internationalization
>>
>>     --  Support for Visual Studio 11
>>
>>     --  Support for Intel C/C++ compiler v12 on Linux and Mac
>>
>>     --  LaTeX support for multibib, biblatex and biber
>>
>>   Please note the following important changes since release 2.0.0:
>>
>>     --  Support for Windows manifest generation
>>
>>     --  SCons now searches sitewide dirs for site_scons
>>
>>     --  Support for Latex bibunits package has been added along with
>>         support for tex files generated by other builders
>>
>>
>>   Please note the following important changes since release 1.3.0:
>>
>>     --  SUPPORT FOR PYTHON VERSIONS PRIOR TO 2.4 HAS BEEN REMOVED
>>
>>         Although SCons is still tested with Python 2.3, use of Python
>>     versions prior to 2.4 is deprecated.
>>
>>     --  DEPRECATED FEATURES WILL GENERATE MANDATORY WARNINGS IN 2.0.0
>>
>>         In keeping with our deprecation cycle, the following deprecated
>>         features will still be supported in 2.0.0 but will generate
>>         mandatory, non-disableable warnings:
>>
>>             --  The overrides= keyword argument to the Builder() call.
>>             --  The scanner= keyword argument to the Builder() call.
>>             --  The BuildDir() function and env.BuildDir() method.
>>             --  The env.Copy() method.
>>             --  The SourceSignatures() function and
>>                 env.SourceSignatures() method.
>>             --  The TargetSignatures() function and
>>                 env.TargetSignatures() method.
>>             --  The Sig module (now an unnused stub).
>>             --  The --debug=dtree, --debug=stree and --debug=tree options.
>>             --  The --debug=nomemoizer option.
>>             --  The Options object and the related BoolOption(),
>>                 EnumOption(), ListOption(), PackageOption() and
>>                 PathOption() functions.
>>
>>         The mandatory warnings will be issued in order to make sure
>>         users of 1.3.0 notice *prior* to the release of SCons 2.0.0, that
>>         these features will be removed.  In SCons 2.0.0 these features
>>         will no longer work at all, and will instead generate specific
>>         fatal errors when anyone tries to use them.
>>
>>   Please note the following important changes since release 1.2.0:
>>
>>     --  MICROSOFT VISUAL STUDIO VERSION/ARCH DETECTION HAS CHANGED
>>
>>         The way SCons detects Visual Studio on Windows has changed in
>>         1.3.  By default, it should now use the latest installed
>>         Visual Studio version on your machine, and compile for 32 or
>>         64 bits according to whether your OS is 32 or 64 bits (32/64
>>         bit Python makes no difference).
>>
>>     Two new variables control Visual Studio: MSVC_VERSION and
>>     TARGET_ARCH.  These variables ONLY take effect when passed to
>>     the Environment() constructor; setting them later has no
>>     effect.  To use a non-default Visual Studio version, set
>>     MSVC_VERSION to e.g. "8.0" or "7.1".  Setting it to "xxx" (or
>>     any nonexistent value) will make it print out the valid
>>     versions on your system.  To use a non-default architecture,
>>     set TARGET_ARCH to "x86" or "x86_64" (various synonyms are
>>     accepted).
>>
>>     Note that if you use MSVS_VERSION to build Visual Studio
>>     projects from your SConstructs, MSVS_VERSION must be set to
>>     the same version as MSVC_VERSION.
>>
>>         Support for HOST_OS,HOST_ARCH,TARGET_OS, TARGET_ARCH has been
>>         added to allow specifying different target arch than the host
>>         system. This is only supported for Visual Studio/Visual C++
>>         at this time.
>>
>>     --  Support for Latex glossaries and acronyms has been added
>>
>>     --  VISUAL C/C++ PRECOMPILED HEADERS WILL BE REBUILT
>>
>>         Precompiled header files built with Visual C/C++ will be
>>         rebuilt after upgrading from 1.2.0 to a later release.
>>
>>         This rebuild is normal and will occur because the command line
>>         defined by the $PCHCOM construction variable has had the $CCFLAGS
>>         variable added, and has been rearranged to put the "/Fo" output
>>         flag towards the beginning of the line, consistent with the
>>         related command lines for $CCCOM, $CXXCOM, etc.
>>
>>     --  CHANGES TO SOME LINKER COMMAND LINES WILL CAUSE RELINKING
>>
>>         Changes to the command line definitions for the Microsoft link.exe
>>         linker, the OS/2 ilink linker and the Phar Lap linkloc linker
>>         will cause targets built with those tools be to be rebuilt after
>>         upgrading from 1.2.0 to a later release.
>>
>>         This relink is normal and will occur because the command lines for
>>         these tools have been redefined to remove unnecessary nested $(
>>         and $) character strings.
>>
>>     --  MSVS_USE_MFC_DIRS and MSVS_IGNORE_IDE_PATHS are obsoleted and
>>         have no effect.
>>
>>   Please note the following important changes since release 1.1.0:
>>
>>     --  THE $CHANGED_SOURCES, $CHANGED_TARGETS, $UNCHANGED_SOURCES
>>         AND $UNCHANGED_TARGETS VARIABLES WILL BECOME RESERVED
>>
>>         A future release (probably 1.3.0) will make the construction
>>         variable names $CHANGED_SOURCES, $CHANGED_TARGETS,
>>         $UNCHANGED_SOURCES and $UNCHANGED_TARGETS into reserved
>>         construction variable names controlled by SCons itself (like
>>         the current $SOURCE, $TARGETS, etc.).
>>
>>         Setting these variable names in the current release will generate
>>         a warning but still set the variables.  When they become reserved
>>         variable names, they will generate a different warning message
>>         and attempts to set these variables will be ignored.
>>
>>         SCons configurations that happen to use these variable names
>>         should be changed to use different variable names, in order
>>         to ensure that the configuration continues to work with future
>>         versions of SCons.
>>
>>     --  THE Options OBJECT AND RELATED FUNCTIONS NOW GENERATE WARNINGS
>>
>>     Use of the Options object, and related functions BoolOption(),
>>     EnumOption(), ListOption(), PackageOption() and PathOption()
>>     were announced as deprecated in release 0.98.1.  Since then,
>>     however, no warning messages were ever implemented for the
>>         use of these deprecated functions.
>>
>>         By default, release 1.2.0 prints warning messages when these
>>         deprecated features are used.  Warnings about all deprecated
>>         features may be suppressed by using the --warn=no-deprecated
>>         command-line option:
>>
>>             $ scons --warn=no-deprecated
>>
>>         Or by using the appropriate SetOption() call in any SConscript
>>         file:
>>
>>             SetOption('warn', 'no-deprecated')
>>
>>         You may optionally disable just warnings about the deprecation
>>         of the Options object and its related functions as follows:
>>
>>             SetOption('warn', 'no-deprecated-options')
>>
>>         The current plan is for these warnings to become mandatory
>>         (non-suppressible) in release 1.3.0, and for the use of Options
>>         and its related functions to generate errors in release 2.0.
>>
>>   Please note the following important changes since release 0.98.4:
>>
>>     --  scons.bat NOW RETURNS THE REAL SCONS EXIT STATUS
>>
>>         The scons.bat script shipped with SCons used to exit with
>>         a status of 1 when it detected any failed (non-zero) exit
>>         status from the underlying Python execution of SCons itself.
>>         The scons.bat script now exits with the actual status
>>         returned by SCons.
>>
>>     --  SCONS NOW WARNS WHEN TRYING TO LINK C++ AND FORTRAN OBJECT FILES
>>
>>         Some C++ toolchains do not understand Fortran runtimes and create
>>         unpredictable executables when linking C++ and Fortran object
>>         files together.  SCons now issues a warning if you try to link
>>         C++ and Fortran object files into the same executable:
>>
>>             scons: warning: Using $CXX to link Fortran and C++ code
>> together.
>>                     This may generate a buggy executable if the
>> '/usr/bin/gcc'
>>                     compiler does not know how to deal with Fortran
>> runtimes.
>>
>>         The warning may be suppressed with either the --warning=no-link
>>         or --warning=no-fortran-cxx-mix command line options, or by
>>         adding either of the following lines to a SConscript file:
>>
>>             SetOption('warn', 'no-link')
>>             SetOption('warn', 'no-fortran-cxx-mix')
>>
>>   Please note the following important changes since release 0.98:
>>
>>     --  SCONS NO LONGER SETS THE GNU TOOLCHAIN -fPIC FLAG IN $SHCXXFLAGS
>>
>>         The GNU toolchain support in previous versions of SCons would
>>         add the -fPIC flag to the $SHCXXFLAGS construction variable.
>>         The -fPIC flag has now been removed from the default
>>         $SHCXXFLAGS setting.  Instead, the $SHCXXCOM construction variable
>>         (the default SCons command line for compiling shared objects
>>         from C++ source files) has been changed to add the $SHCCFLAGS
>>         variable, which contains the -fPIC flag.
>>
>>         This change was made in order to make the behavior of the default
>>         C++ compilation line including $SHCCFLAGS consistent with the
>>         default C compilation line including $CCFLAGS.
>>
>>         This change should have no impact on configurations that use
>>         the default $SHCXXCOM command line.  It may have an impact on
>>         configurations that were using the default $SHCXXFLAGS value
>>         *without* the $SHCCFLAGS variable to get the -fPIC flag into a
>>         custom command line.  You can fix these by adding the $SHCCFLAGS
>>         to the custom command line.
>>
>>         Adding $SHCCFLAGS is backwards compatible with older SCons
>>         releases, although it might cause the -fPIC flag to be repeated
>>         on the command line if you execute it on an older version of
>>         SCons that sets -fPIC in both the $SHCCLAFGS and $SHCXXFLAGS
>>         variables.  Duplicating the -fPIC flag on the g++ command line
>>         will not cause any compilation problems, but the change to the
>>         command line may cause SCons to rebuild object files.
>>
>>     --  FORTRAN NOW COMPILES .f FILES WITH gfortran BY DEFAULT
>>
>>         The Fortran Tool modules have had a major overhaul with the intent
>>         of making them work as-is for most configurations.  In general,
>>         most configurations that use default settings should not see
>>         any noticeable difference.
>>
>>         One configuration that has changed is if you have both a gfortran
>>         and g77 compiler installed.  In this case, previous versions of
>>         SCons would, by default, use g77 by default to compile files with
>>         a .f suffix, while SCons 0.98.1 will use the gfortran compiler
>>         by default.  The old behavior may be preserved by explicitly
>>         initializing construction environments with the 'g77' Tool module:
>>
>>             env = Environment(tools = ['g77', 'default'])
>>
>>         The above code is backwards compatible to older versions of SCons.
>>
>>         If you notice any other changes in the behavior of default
>>         Fortran support, please let us know so we can document them in
>>         these release notes for other users.
>>
>>   Please note the following important changes since release
>> 0.97.0d20071212:
>>
>>     --  SUPPORT FOR PYTHON VERSIONS BEFORE 2.2 IS NOW DEPRECATED
>>
>>         SCons now prints the following warning when it is run by any
>>         Python 1.5, 2.0 or 2.1 release or sub-release:
>>
>>             scons: warning: Support for pre-2.2 Python (VERSION) is
>> deprecated.
>>                 If this will cause hardship, contact scons-dev at scons.org
>>
>>         You may disable all warnings about deprecated features by adding
>>         the option "--warn=no-deprecated" to the command line or to the
>>         $SCONSFLAGS environment variable:
>>
>>             $ scons --warn=no-deprecated
>>
>>         Using '--warn=no-deprecated' is compatible with earlier versions
>>         of SCons.
>>
>>         You may also, as of this version of SCons, disable all warnings
>>         about deprecated features by adding the following to any
>>         SConscript file:
>>
>>             SetOption('warn', 'no-deprecated')
>>
>>         You may disable only the specific warning about running under
>>         a deprecated Python version by adding the following to any
>>         SConscript file:
>>
>>             SetOption('warn', 'no-python-version')
>>
>>         The warning may also be suppressed on the command line:
>>
>>             $ scons --warn=no-python-version
>>
>>         Or by specifying the --warn=no-python-version option in the
>>         $SCONSFLAGS environment variable.
>>
>>         Using SetOption('warn', ...), and the 'no-python-version'
>>         command-line option for suppressing this specific warning,
>>         are *not* backwards-compatible to earlier versions of SCons.
>>
>>     --  THE env.Copy() METHOD IS NOW OFFICIALLY DEPRECATED
>>
>>         The env.Copy() method is now officially deprecated and will
>>         be removed in a future release.  Using the env.Copy() method
>>         now generates the following message:
>>
>>             scons: warning: The env.Copy() method is deprecated; use the
>> env.Clone() method instead.
>>
>>         You may disable all warnings about deprecated features by adding
>>         the option "--warn=no-deprecated" to the command line or to the
>>         $SCONSFLAGS environment variable:
>>
>>             $ scons --warn=no-deprecated
>>
>>         Using '--warn=no-deprecated' is compatible with earlier versions
>>         of SCons.
>>
>>         You may also, as of this version of SCons, disable all warnings
>>         about deprecated features by adding the following to any
>>         SConscript file:
>>
>>             SetOption('warn', 'no-deprecated')
>>
>>     You may disable only the specific warning about the deprecated
>>     env.Copy() method by adding the following to any SConscript
>>     file:
>>
>>             SetOption('warn', 'no-deprecated-copy')
>>
>>         The warning may also be suppressed on the command line:
>>
>>             $ scons --warn=no-deprecated-copy
>>
>>         Or by specifying the --warn=no-deprecated-copy option in the
>>         $SCONSFLAGS environment variable.
>>
>>         Using SetOption('warn', ...), and the 'no-deprecated-copy'
>>         command-line option for suppressing this specific warning,
>>         are *not* backwards-compatible to earlier versions of SCons.
>>
>>     --  THE --debug=dtree, --debug=stree AND --debug=tree OPTIONS ARE
>> DEPRECATED
>>
>>         The --debug=dtree, --debug=stree and --debug=tree methods
>>         are now officially deprecated and will be removed in a
>>         future release.  Using these options now generate a warning
>>         message recommending use of the --tree=derived, --tree=all,status
>>         and --tree=all options, respectively.
>>
>>         You may disable these warnings, and all warnings about
>>         deprecated features, by adding the option "--warn=no-deprecated"
>>         to the command line or to the $SCONSFLAGS environment
>>         variable:
>>
>>             $ scons --warn=no-deprecated
>>
>>         Using '--warn=no-deprecated' is compatible with earlier versions
>>         of SCons.
>>
>>     --  THE TargetSignatures() AND SourceSignatures() FUNCTIONS ARE
>> DEPRECATED
>>
>>     The TargetSignatures() and SourceSignatures() functions,
>>     and their corresponding env.TargetSignatures() and
>>     env.SourceSignatures() methods, are now officially deprecated
>>     and will be be removed in a future release.  Using ahy of
>>     these functions or methods now generates a message
>>     similar to the following:
>>
>>             scons: warning: The env.TargetSignatures() method is
>> deprecated;
>>                     convert your build to use the env.Decider() method
>> instead.
>>
>>         You may disable all warnings about deprecated features by adding
>>         the option "--warn=no-deprecated" to the command line or to the
>>         $SCONSFLAGS environment variable:
>>
>>             $ scons --warn=no-deprecated
>>
>>         Using '--warn=no-deprecated' is compatible with earlier versions
>>         of SCons.
>>
>>         You may also, as of this version of SCons, disable all warnings
>>         about deprecated features by adding the following to any
>>         SConscript file:
>>
>>             SetOption('warn', 'no-deprecated')
>>
>>     You may disable only the specific warning about the use of
>>     TargetSignatures() or SourceSignatures() by adding the
>>     following to any SConscript file:
>>
>>             SetOption('warn', 'no-deprecated-target-signatures')
>>             SetOption('warn', 'no-deprecated-source-signatures')
>>
>>         The warnings may also be suppressed on the command line:
>>
>>             $ scons --warn=no-deprecated-target-signatures
>> --warn=no-deprecated-source-signatures
>>
>>     Or by specifying these options in the $SCONSFLAGS environment
>>     variable.
>>
>>     Using SetOption('warn', ...), or the command-line options
>>     for suppressing these warnings, is *not* backwards-compatible
>>     to earlier versions of SCons.
>>
>>     --  File(), Dir() and Entry() NOW RETURN A LIST WHEN THE INPUT IS A
>> SEQUENCE
>>
>>         Previously, if these methods were passed a list, the list was
>>         substituted and stringified, then passed as a single string to
>>         create a File/Dir/Entry Node.  This rarely if ever worked with
>>         more than one element in the list.  They now return a list of
>>         Nodes when passed a list.
>>
>>         One case that works differently now is a passing in a
>>         single-element sequence; that formerly was stringified
>>         (returning its only element) and then a single Node would be
>>         returned.  Now a single-element list containing the Node will
>>         be returned, for consistency.
>>
>>     --  THE env.subst() METHOD NOW RETURNS A LIST WHEN THE INPUT IS A
>> SEQUENCE
>>
>>         The env.subst() method now returns a list with the elements
>>         expanded when given a list as input.  Previously, the env.subst()
>>         method would always turn its result into a string.
>>
>>         This behavior was changed because it interfered with being able
>>         to include things like lists within the expansion of variables
>>         like $CPPPATH and then have SCons understand that the elements
>>         of the "internal" lists still needed to be treated separately.
>>         This would cause a $CPPPATH list like ['subdir1', 'subdir']
>>         to show up in a command line as "-Isubdir1 subdir".
>>
>>     --  THE Jar() BUILDER NOW USES THE Java() BUILDER CLASSDIR BY DEFAULT
>>
>>         By default, the Jar() Builder will now use the class directory
>>         specified when the Java() builder is called.  So the following
>>         input:
>>
>>             classes = env.Java('classes', 'src')
>>             env.Jar('out.jar', classes)
>>
>>         Will cause "-C classes" to be passed the "jar" command invocation,
>>         and the Java classes in the "out.jar" file will not be prefixed
>>         "classes/".
>>
>>         Explicitly setting the $JARCHDIR variable overrides this default
>>         behavior.  The old behavior of not passing any -C option to the
>>         "jar" command can be preserved by explicitly setting $JARCHDIR
>>         to None:
>>
>>             env = Environment(JARCHDIR = None)
>>
>>         The above setting is compatible with older versions of SCons.
>>
>>   Please note the following important changes since release
>> 0.97.0d20070918:
>>
>>     --  SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS
>>         ON OPEN FILE HANDLES TO CREATED PROCESSES
>>
>>         On Windows systems, SCons now redefines the Python open()
>>         and file() functions so that, if the Python Win32 extensions
>>         are available, the file handles for any opened files will *not*
>>         be inherited by subprocesses, such as the spawned compilers and
>>         other tools invoked to build the software.
>>
>>         This prevents certain race conditions where a file handle for
>>         a file opened by Python (either in a Python function action,
>>         or directly in a SConscript file) could be inherited and help
>>         open by a subprocess, interfering with the ability of other
>>         processes to create or modify the file.
>>
>>         In general, this should not cause problems for the vast majority
>>         of configurations.  The only time this would be a problem would be
>>         in the unlikely event that a process spawned by SCons specifically
>>         *expected* to use an inherited file handle opened by SCons.
>>
>>         If the Python Win32 extensions are not installed or are an
>>         earlier version that does not have the ability to disable file
>>         handle inheritance, SCons will print a warning message when the
>>         -j option is used.  The warning message may be suppressed by
>>         specifying --warn=no-parallel-support.
>>
>>   Please note the following important changes since release
>> 0.97.0d20070809:
>>
>>     --  "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR
>>
>>         The default behavior of SCons is now to use the MD5 checksum of
>>         all file contents to decide if any files have changed and should
>>         cause rebuilds of their source files.  This means that SCons may
>>         decide not to rebuild "downstream" targets if a a given input
>>         file is rebuilt to the exact same contents as the last time.
>>         The old behavior may preserved by explicity specifying:
>>
>>             TargetSignatures("build")
>>
>>         In any of your SConscript files.
>>
>>     --  TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM
>>
>>         For all targets built by calling external commands (such as a
>>         compiler or other utility), SCons now adds an implicit dependency
>>         on the command(s) used to build the target.
>>
>>         This will cause rebuilds of all targets built by external commands
>>         when running SCons in a tree built by previous version of SCons,
>>         in order to update the recorded signatures.
>>
>>         The old behavior of not having targets depend on the external
>>         commands that build them can be preserved by setting a new
>>         $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a
>>         non-True value:
>>
>>             env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0)
>>
>>         or by adding Ignore() calls for any targets where the behavior
>>         is desired:
>>
>>             Ignore('/usr/bin/gcc', 'foo.o')
>>
>>         Both of these settings are compatible with older versions
>>         of SCons.
>>
>>     --  CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS
>>
>>         If you change the SourceSignature() value from 'timestamp' to
>>         'MD5', SCons will now rebuild targets that were already up-to-date
>>         with respect to their source files.
>>
>>         This will happen because SCons did not record the content
>>         signatures of the input source files when the target was last
>>         built--it only recorded the timestamps--and it must record them
>>         to make sure the signature information is correct.  However,
>>         the content of source files may have changed since the last
>>         timestamp build was performed, and SCons would not have any way to
>>         verify that.  (It would have had to open up the file and record
>>         a content signature, which is one of the things you're trying to
>>         avoid by specifying use of timestamps....)  So in order to make
>>         sure the built targets reflect the contents of the source files,
>>         the targets must be rebuilt.
>>
>>         Change the SourceSignature() value from 'MD5' to 'timestamp'
>>         should correctly not rebuild target files, because the timestamp
>>         of the files is always recorded.
>>
>>         In previous versions of SCons, changing the SourceSignature()
>>         value would lead to unpredictable behavior, usually including
>>         rebuilding targets.
>>
>>     --  THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY
>>
>>         The Return() function now immediately stops processing the
>>         SConscript file in which it appears and returns the values of the
>>         variables named in its arguments.  It used to continue processing
>>         the rest of the SConscript file, and then return the values of the
>>         specified variables at the point the Return() function was called.
>>
>>         The old behavior may be requested by adding a "stop=False"
>>         keyword argument to the Return() call:
>>
>>                 Return('value', stop=False)
>>
>>         The "stop=" keyword argument is *not* compatible with SCons
>>         versions 0.97.0d20070809 or earlier.
>>
>>   Please note the following important changes since release 0.97:
>>
>>     --  env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS
>>
>>         The env.CacheDir() method now only causes derived files to be
>>         retrieved from the specified cache directory for targets built
>>         with the specified specified construction environment ("env").
>>
>>         Previously, any call to env.CacheDir() or CacheDir() would modify
>>         a global setting and cause all built targets to be retrieved
>>         from the specified cache directory.  This behavior was changed so
>>         that env.CacheDir() would be consistent with other construction
>>         environment methods, which only affect targets built with the
>>         specified construction environment.
>>
>>         The old behavior of changing the global behavior may be preserved
>>         by changing any env.CacheDir() calls to:
>>
>>                 CacheDir('/path/to/cache/directory')
>>
>>         The above change is backwards-compatible and works in all earlier
>>         versions of SCons that support CacheDir().
>>
>>     --  INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED
>>
>>         The interpretation of source arguments (files) without suffixes
>>         has changed in one specific configuration.
>>
>>         Previously, if a Builder had a src_suffix specified (indicating
>>         that source files without suffixes should have that suffix
>>         appended), the suffix would only be applied to suffix-less source
>>         arguments if the Builder did *not* have one or more attached
>>         source Builders (that is, the Builder was not a "multi-stage"
>>         Builder).  So in the following configuration:
>>
>>                 build_foo = Builder(src_suffix = '.foo')
>>                 build_bar = Builder(src_suffix = '.bar',
>>                                     src_builder = build_bar)
>>
>>                 env = Environment(BUILDERS = {
>>                                    'Foo' : build_foo,
>>                                    'Boo' : build_bar,
>>                                   })
>>
>>                 env.Foo('tgt1', 'src1')
>>                 env.Bar('tgt2', 'src2')
>>
>>         SCons would have expected to find a source file 'src1.foo' for the
>>         env.Foo() call, but a source file 'src2' for the env.Bar() call.
>>
>>         This behavior has now been made consistent, so that the two
>>         above calls would expect source files named 'src1.foo' and
>>         'src2.bar', respectively.
>>
>>         Note that, if genuinely desired, the old behavior of building
>>         from a source file without a suffix at all (when the Builder has
>>         a src_suffix *and* a src_builder) can be specified explicity by
>>         turning the string into a File Node directly:
>>
>>                 env.Bar('tgt2', File('src2'))
>>
>>         The above use of File() is backwards-compatible and will work
>>         on earlier versions of SCons.
>>
>>     --  THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED
>>
>>         On Solaris systems, SCons now adds the "/opt/SUNWspro/bin"
>>         directory to the default execution $PATH variable before the
>>         "/usr/ccs/bin" directory.  This was done to reflect the fact
>>         that /opt/SUNWspro/ is the default for SUN tools, but it may
>>         cause a different compiler to be used if you have compilers
>>         installed in both directories.
>>
>>     --  GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1"
>>
>>         When generating a "config.h" file, SCons now defines values that
>>         record the existence of a feature with a "1" value:
>>
>>             #define HAVE_FEATURE 1
>>
>>         Instead of printing the line without a "1", as it used to:
>>
>>             #define HAVE_FEATURE
>>
>>         This should not cause any problems in the normal use of "#ifdef
>>         HAVE_{FEATURE}" statements interpreted by a C preprocessor, but
>>         might cause a compatibility issue if a script or other utility
>>         looks for an exact match of the previous text.
>>
>>   Please note the following planned, future changes:
>>
>>     --  THE Options OBJECT AND RELATED FUNCTIONS WILL BE DEPRECATED
>>
>>         The Options object is being replaced by a new Variables
>>         object, which uses a new Variables.AddVariable() method
>>         where the previous interface used Options.AddOptions().
>>
>>         Similarly, the following utility functions are being replaced
>>         by the following similarly-named functions:
>>
>>                 BoolOption()            BoolVariable()
>>                 EnumOption()            EnumVariable()
>>                 ListOption()            ListVariable()
>>                 PackageOption()         PackageVariable()
>>                 PathOption()            PathVariable()
>>
>>         And also related, the options= keyword argument when creating
>>         construction environments with the Environment() functions is
>>         being replaced with a variables= keyword argument.
>>
>>         In some future release a deprecation warning will be added to
>>         existing uses of the Options object, its methods, the above
>>         utility functions, and the options= keyword argument of the
>>         Environment() function.  At some point after the deprecation
>>         warning is added, the Options object, related functions and
>>         options= keyword argument will be removed entirely.
>>
>>         You can prepare for this by changing all your uses of the Options
>>         object and related functions to the Variables object and the new
>>         function names, and changing any uses of the options= keyword
>>         argument to variables=.
>>
>>         NOTE:  CONVERTING TO USING THE NEW Variables OBJECT OR THE
>>         RELATED *Variable() FUNCTIONS, OR USING THE NEW variable=
>>         KEYWORD ARGUMENT, IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF
>>         SCons BEFORE 0.98.  YOUR SConscript FILES WILL NOT WORK ON
>>         EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE.
>>
>>         If you change SConscript files in software that you make available
>>         for download or otherwise distribute, other users may try to
>>         build your software with an earlier version of SCons that does
>>         not have the Variables object or related *Variable() functions.
>>         We recommend preparing for this in one of two ways:
>>
>>             --  Make your SConscript files backwards-compatible by
>>                 modifying your calls with  Python try:-except: blocks
>>                 as follows:
>>
>>                     try:
>>                         vars = Variables('custom.py', ARGUMENTS)
>>                         vars.AddVariables(
>>                             BoolVariable('WARNINGS', 'cmopile with
>> -Wall', 1),
>>                             EnumVariable('DEBUG', 'debug version', 'no'
>>                                        allowed_values=('yes', 'no',
>> 'full'),
>>                                        map={}, ignorecase=0),
>>                             ListVariable('SHAREDLIBS',
>>                                          'libraries to build shared',
>>                                          'all',
>>                                          names = list_of_libs),
>>                             PackageVariable('X11',
>>                                             'use X11 from here',
>>                                             '/usr/bin/X11'),
>>                             PathVariable('QTDIR', 'root of Qt', qtdir),
>>                         )
>>                     except NameError:
>>                         vars = Options('custom.py', ARGUMENTS)
>>                         vars.AddOptions(
>>                             BoolOption('WARNINGS', 'cmopile with -Wall',
>> 1),
>>                             EnumOption('DEBUG', 'debug version', 'no'
>>                                        allowed_values=('yes', 'no',
>> 'full'),
>>                                        map={}, ignorecase=0),
>>                             ListOption('SHAREDLIBS',
>>                                        'libraries to build shared',
>>                                        'all',
>>                                        names = list_of_libs),
>>                             PackageOption('X11',
>>                                           'use X11 from here',
>>                                           '/usr/bin/X11'),
>>                             PathOption('QTDIR', 'root of Qt', qtdir),
>>                         )
>>
>>                 Additionally, you can check for availability of the new
>>                 variables= keyword argument as follows:
>>
>>                     try:
>>                         env = Environment(variables=vars)
>>                     except TypeError:
>>                         env = Environment(options=vars)
>>
>>                 (Note that we plan to maintain the existing Options object
>>                 name for some time, to ensure backwards compatibility,
>>                 so in practice it may be easier to just continue to use
>>                 the old name until you're reasonably sure you won't have
>>                 people trying to build your software with versions of
>>                 SCons earlier than 0.98.1.)
>>
>>             --  Use the EnsureSConsVersion() function to provide a
>>                 descriptive error message if your SConscript files
>>                 are executed by an earlier version of SCons:
>>
>>                     EnsureSConsVersion(0, 98, 1)
>>
>>     --  THE BuildDir() METHOD AND FUNCTION WILL BE DEPRECATED
>>
>>         The env.BuildDir() method and BuildDir() function are being
>>         replaced by the new env.VariantDir() method and VariantDir()
>>         function.
>>
>>         In some future release a deprecation warning will be added
>>         to existing uses of the env.BuildDir() method and BuildDir()
>>         function.  At some point after the deprecation warning, the
>>         env.Builder() method and BuildDir() function will either
>>         be removed entirely or have their behavior changed.
>>
>>     You can prepare for this by changing all your uses of the
>>     env.BuildDir() method to env.VariantDir() and uses of the
>>     global BuildDir() function to VariantDir().  If you use a
>>     named keyword argument of "build_dir" when calling
>>     env.BuildDir() or BuildDir():
>>
>>             env.BuildDir(build_dir='opt', src_dir='src')
>>
>>         The keyword must be changed to "variant_dir":
>>
>>             env.VariantDir(variant_dir='opt', src_dir='src')
>>
>>         NOTE:  CHANGING USES OF env.BuildDir() AND BuildDir() to
>>         env.VariantDir() AND VariantDir() IS NOT BACKWARDS COMPATIBLE
>>         TO VERSIONS OF SCons BEFORE 0.98.  YOUR SConscript FILES
>>         WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING
>>         THIS CHANGE.
>>
>>         If you change SConscript files in software that you make
>>         available for download or otherwise distribute, other users
>>         may try to build your software with an earlier version of
>>         SCons that does not have the env.VariantDir() method or
>>         VariantDir() fnction.  We recommend preparing for this in
>>         one of two ways:
>>
>>             --  Make your SConscript files backwards-compatible by
>>                 including the following code near the beginning of your
>>                 top-level SConstruct file:
>>
>>                     import SCons.Environment
>>                     try:
>>                         SCons.Environment.Environment.VariantDir
>>                     except AttributeError:
>>                         SCons.Environment.Environment.VariantDir = \
>>                               SCons.Environment.Environment.BuildDir
>>
>>             --  Use the EnsureSConsVersion() function to provide a
>>                 descriptive error message if your SConscript files
>>                 are executed by an earlier version of SCons:
>>
>>                     EnsureSConsVersion(0, 98)
>>
>>     --  THE SConscript() "build_dir" KEYWORD ARGUMENT WILL BE DEPRECATED
>>
>>     The "build_dir" keyword argument of the SConscript function
>>     and env.SConscript() method are being replaced by a new
>>     "variant_dir" keyword argument.
>>
>>     In some future release a deprecation warning will be added
>>     to existing uses of the SConscript()/env.SConscript()
>>     "build_dir" keyword argument.  At some point after the
>>     deprecation warning, support for this keyword argument will
>>     be removed entirely.
>>
>>     You can prepare for this by changing all your uses of the
>>     SConscript()/env.SConscript() 'build_dir" keyword argument:
>>
>>             SConscript('src/SConscript', build_dir='opt')
>>
>>         To use the new "variant_dir" keyword argument:
>>
>>             SConscript('src/SConscript', variant_dir='opt')
>>
>>     NOTE:  USING THE NEW "variant_dir" KEYWORD IS NOT BACKWARDS
>>     COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98.  YOUR SConscript
>>     FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER
>>     MAKING THIS CHANGE.
>>
>>     If you change SConscript files in software that you make
>>     available for download or otherwise distribute, other users
>>     may try to build your software with an earlier version of
>>     SCons that does not support the "variant_dir" keyword.
>>
>>     If you can insist that users use a recent version of SCons
>>     that supports "variant_dir", we recommend using the
>>     EnsureSConsVersion() function to provide a descriptive error
>>     message if your SConscript files are executed by an earlier
>>     version of SCons:
>>
>>                     EnsureSConsVersion(0, 98)
>>
>>     If you want to make sure that your SConscript files will
>>     still work with earlier versions of SCons, then your best
>>     bet is to continue to use the "build_dir" keyword until the
>>     support is removed (which, in all likelihood, won't happen
>>     for quite some time).
>>
>>     --  SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
>>
>>         Several internal variable names in SCons.Defaults for various
>>         pre-made default Scanner objects have been deprecated and will
>>         be removed in a future revision.  In their place are several new
>>         global variable names that are now part of the publicly-supported
>>         interface:
>>
>>             NEW NAME              DEPRECATED NAME
>>             --------              ----------------------------
>>             CScanner              SCons.Defaults.CScan
>>             DSCanner              SCons.Defaults.DScan
>>             SourceFileScanner     SCons.Defaults.ObjSourceScan
>>             ProgramScanner        SCons.Defaults.ProgScan
>>
>>         Of these, only ObjSourceScan was probably used at all, to add
>>         new mappings of file suffixes to other scanners for use by the
>>         Object() Builder.  This should now be done as follows:
>>
>>             SourceFileScanner.add_scanner('.x', XScanner)
>>
>>     --  THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY
>>
>>         The env.Copy() method (to make a copy of a construction
>>         environment) is being replaced by the env.Clone() method.
>>
>>         As of SCons 0.98, a deprecation warning has been added to
>>         current uses of the env.Copy() method.  At some point in
>>         the future, the env.Copy() method will either be removed
>>         entirely or have its behavior changed.
>>
>>         You can prepare for this by changing all your uses of env.Copy()
>>         to env.Clone(), which has the exact same calling arguments.
>>
>>         NOTE:  CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE
>>         YOUR SConscript FILES NOT WORK ON VERSIONS OF SCons BEFORE
>>         0.96.93.
>>
>>         If you change SConscript files in software that you make
>>         available for download or otherwise distribute, other users
>>         may try to build your software with an earlier version of
>>         SCons that does not have the env.Clone() method.  We recommend
>>         preparing for this in one of two ways:
>>
>>             --  Make your SConscript files backwards-compatible by
>>                 including the following code near the beginning of your
>>                 top-level SConstruct file:
>>
>>                     import SCons.Environment
>>                     try:
>>                         SCons.Environment.Environment.Clone
>>                     except AttributeError:
>>                         SCons.Environment.Environment.Clone = \
>>                               SCons.Environment.Environment.Copy
>>
>>             --  Use the EnsureSConsVersion() function to provide a
>>                 descriptive error message if your SConscript files
>>                 are executed by an earlier version of SCons:
>>
>>                     EnsureSConsVersion(0, 96, 93)
>>
>>     --  THE CheckLib Configure TEST WILL CHANGE BEHAVIOR
>>
>>         The CheckLib() Configure test appends the lib(s) to the
>>         Environment's LIBS list in 1.3 and earlier.  In 1.3 there is a
>>         new CheckLib argument, append, which defaults to True to
>>         preserve the old behavior.  In a future release, append will
>>         be changed to default to False, to conform with autoconf and
>>         user expectations, since it is usually used to build up
>>         library lists in a right-to-left way.
>>
>>
>>
>>   SCons is developed with an extensive regression test suite, and a
>>   rigorous development methodology for continually improving that suite.
>>   Because of this, SCons is of sufficient quality that you can use it
>>   for real work.
>>
>>   The interfaces in release 1.0 will *not* be knowingly changed in
>>   any new, future 1.x release.  If an interface change should ever
>>   become necessary due to extraordinary circumstances, the change
>>   and an appropriate transition strategy will be documented in these
>>   RELEASE notes.
>>
>>   As you use SCons, please heed the following:
>>
>>     - Please report any bugs or other problems that you find to our bug
>>       tracker at our SourceForge project page:
>>
>>       http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
>>
>>       We have a reliable bug-fixing methodology already in place and
>>       strive to respond to problems relatively quickly.
>>
>>     - Documentation is spottier than we'd like.  You may need to dive
>>       into the source code to figure out how to do something.  Asking
>>       questions on the scons-users mailing list is also welcome.  We
>>       will be addressing the documentation in upcoming releases, but
>>       would be more than glad to have your assistance in correcting this
>>       problem... :-)
>>
>>     - The "SCons Design" documentation on the SCons web site is very
>>       out of date, as we made significant changes to portions of the
>>       interface as we figured out what worked and what didn't during the
>>       extensive beta implementation.  The "SCons Design" document should
>>       be used only for historical purposes, or for just an extremely
>>       general understanding of SCons' architectural goals.
>>
>>     - There may be performance issues.  Improving SCons performance
>>       is an ongoing priority.  If you still find the performance
>>       unacceptable, we would very much like to hear from you and learn
>>       more about your configuration so we can optimize the right things.
>>
>>     - Error messages don't always exist where they'd be helpful.
>>       Please let us know about any errors you ran into that would
>>       have benefitted from a (more) descriptive message.
>>
>>   KNOWN PROBLEMS IN THIS RELEASE:
>>
>>     For a complete list of known problems, consult the SCons Issue Tracker
>>     at tigris.org:
>>
>>         http://scons.tigris.org/project_issues.html
>>
>>     - Support for parallel builds (-j) does not work on WIN32 systems
>>       prior to *official* Python release 2.2 (not 2.2 pre-releases).
>>
>>       Prior to Python 2.2, there is a bug in Python's Win32
>>       implementation such that when a thread spawns an external command,
>>       it blocks all threads from running.  This breaks the SCons
>>       multithreading architecture used to support -j builds.
>>
>>       We have included a patch file, os_spawnv_fix.diff, that you can
>>       use if you you want to fix your version of Python to support
>>       parallel builds in SCons.
>>
>>     - Again, the "SCons Design" documentation on the SCons web site is
>>       out of date.  Take what you read there with a grain of salt.
>>
>>     - On Win32 systems, you must put a space between the redirection
>>       characters < and >, and the specified files (or construction
>>       variable expansions):
>>
>>         command < $SOURCE > $TARGET
>>
>>       If you don't supply a space (for example, "<$SOURCE"), SCons will
>>       not recognize the redirection.
>>
>>     - MSVC .res files are not rebuilt when icons change.
>>
>>     - The -c option does not clean up .sconsign files or directories
>>       created as part of the build, and also does not clean up
>>       SideEffect files (for example, Visual Studio .pdb files).
>>
>>     - When using multiple Repositories, changing the name of an include
>>       file can cause an old version of the file to be used.
>>
>>     - There is currently no way to force use of a relative path (../*)
>>       for directories outside the top-level SConstruct file.
>>
>>     - The Jar() Builder will, on its second or subsequent invocation,
>>       package up the .sconsign files that SCons uses to track signatures.
>>       You can work around this by using the SConsignFile() function
>>       to collect all of the .sconsign information into a single file
>>       outside of the directory being packaged by Jar().
>>
>>     - SCons does not currently have a way to detect that an intermediate
>>       file has been corrupted from outside and should be rebuilt.
>>
>>     - Unicode characters in path names do not work in all circumstances.
>>
>>     - SCons does not currently automatically check out SConstruct or
>>       SConscript files from SCCS, RCS or BitKeeper.
>>
>>     - No support yet for the following planned command-line options:
>>
>>          -d -e -l --list-actions --list-derived --list-where
>>          -o --override -p -r -R -w --write-filenames
>>          -W --warn-undefined-variables
>>
>>
>>
>> Thank you for your interest, and please let us know how we can help
>> improve SCons for your needs.
>>
>> -- The SCons Development Team
>>    Gary Oberbrunner and Bill Deegan, maintainers
>>    Thanks to all the contributors for all your help!
>>
>> Copyright (c) 2001 - 2015 The SCons Foundation
>>
>>
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150922/1b6467c8/attachment-0001.html>


More information about the Scons-dev mailing list