Release Notes
-This is a beta release of 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.
+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.
So that everyone using SCons can help each other learn how to use it
-more effectively, please sign up for the scons-users mailing list at:
+more effectively, please sign up for the scons-users mailing list using
+the instructions on the following page:
+
+ http://scons.org/lists.php
+
+
- http://lists.sourceforge.net/lists/listinfo/scons-users
+RELEASE 1.3.0 - Tue, 23 Mar 2010 21:44:19 -0400
+ Please consult the CHANGES.txt file for a list of specific changes
+ since last release.
+ Please note the following important changes in this release:
-RELEASE 0.98.4 - Sat, 17 May 2008 22:14:46 -0700
+ -- DEPRECATED FEATURES WILL GENERATE MANDATORY WARNINGS IN 1.3.0
+
+ In keeping with our deprecation cycle, the following deprecated
+ features will still be supported in 1.3.0 but will generate
+ mandatory, non-disableable warnings:
+
+ -- Support for Python versions 1.5, 1.6, 2.0, 2.1, 2.2, and 2.3.
+ -- 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).
+
+ In addition, MSVC_USE_SCRIPT can be used to bypass the
+ above autodetection; setting it to the path of a Visual
+ Studio .bat file (e.g. vcvars.bat) will cause SCons to
+ run that bat file and extract the relevant variables
+ from the result (typically %INCLUDE%, %LIB%, and %PATH%).
+ Setting MSVC_USE_SCRIPT to None bypasses the Visual Studio
+ autodetection entirely; use this if you are importing
+ the shell env and running SCons in a Visual Studio cmd window.
+
+ 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:
- This is a release candidate for SCons 1.0. Please consult the
- CHANGES.txt file for a list of specific changes since last release.
+ $ 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:
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 "beta" status of the release reflects that we
- still may change interfaces in future releases, which may require
- modifications to your SConscript files. We strive to hold these
- changes to a minimum.
+ 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.
- Nevertheless, please heed the following disclaimers:
+ 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:
would be more than glad to have your assistance in correcting this
problem... :-)
- In particular, the "SCons Design" documentation on the SCons web
- site is currently out of date, as we made significant changes to
- portions of the interface as we figured out what worked and what
- didn't during implementation.
+ - 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
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 currently out of date. Take what you read there with a
- grain of salt.
+ - 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
With plenty of help from the SCons Development team:
Chad Austin
Charles Crain
+ Bill Deegan
Steve Leblanc
+ Greg Noel
Gary Oberbrunner
Anthony Roach
Greg Spencer
projects / scons.git / blobdiff