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 <[email protected]> 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 [email protected] > > 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 > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
