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
