Since we are officially done with versions of python prior to 2.7.X, would anyone be opposed to refactor work to get rid of some legacy code? I am sure we are all aware of code that can be simplified or removed for newer standard library calls.
On Tue, Sep 22, 2015 at 1:06 AM, William Blevins <[email protected]> wrote: > 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 <[email protected]> > 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 <[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
