2 # __FILE__ __REVISION__ __DATE__ __DEVELOPER__
5 SCons - a software construction tool
10 This is SCons, a tool for building software (and other files). SCons is
11 implemented in Python, and its "configuration files" are actually Python
12 scripts, allowing you to use the full power of a real scripting language
13 to solve build problems. You do not, however, need to know Python to
14 use SCons effectively.
16 So that everyone using SCons can help each other learn how to use it
17 more effectively, please sign up for the scons-users mailing list at:
19 http://lists.sourceforge.net/lists/listinfo/scons-users
23 RELEASE 1.2.0.d20090223 - Mon, 23 Feb 2009 08:41:06 -0800
25 Please consult the CHANGES.txt file for a list of specific changes
28 Please note the following important changes scheduled for the next
29 minor release (1.3.0):
31 -- DEPRECATED FEATURES WILL GENERATE MANDATORY WARNINGS IN 1.3.0
33 In keeping with our deprecation cycle, the following deprecated
34 features will still be supported in 1.3.0 but will generate
35 mandatory, non-disableable warnings:
37 -- Support for Python versions 1.5, 1.6, 2.0, 2.1, 2.2 and 2.3.
38 -- The overrides= keyword argument to the Builder() call.
39 -- The scanner= keyword argument to the Builder() call.
40 -- The BuildDir() function and env.BuildDir() method.
41 -- The env.Copy() method.
42 -- The SourceSignatures() function and
43 env.SourceSignatures() method.
44 -- The TargetSignatures() function and
45 env.TargetSignatures() method.
46 -- The Sig module (now an unnused stub).
47 -- The --debug=dtree, --debug=stree and --debug=tree options.
48 -- The --debug=nomemoizer option.
49 -- The Options object and the related BoolOption(),
50 EnumOption(), ListOption(), PackageOption() and
51 PathOption() functions.
53 The mandatory warnings will be issued in order to make sure
54 users of 1.3.0 notice *prior* to the release of SCons 2.0.0, that
55 these features will be removed. In SCons 2.0.0 these features
56 will no longer work at all, and will instead generate specific
57 fatal errors when anyone tries to use them.
59 Please note the following important changes since release 1.2.0:
61 -- VISUAL C/C++ PRECOMPILED HEADERS WILL BE REBUILT
63 Precompiled header files built with Visual C/C++ will be
64 rebuilt after upgrading from 1.2.0 to a later release.
66 This rebuild is normal and will occur because the command line
67 defined by the $PCHCOM construction variable has had the $CCFLAGS
68 variable added, and has been rearranged to put the "/Fo" output
69 flag towards the beginning of the line, consistent with the
70 related command lines for $CCCOM, $CXXCOM, etc.
72 -- CHANGES TO SOME LINKER COMMAND LINES WILL CAUSE RELINKING
74 Changes to the command line definitions for the Microsoft link.exe
75 linker, the OS/2 ilink linker and the Phar Lap linkloc linker
76 will cause targets built with those tools be to be rebuilt after
77 upgrading from 1.2.0 to a later release.
79 This relink is normal and will occur because the command lines for
80 these tools have been redefined to remove unnecessary nested $(
81 and $) character strings.
83 -- MSVS_USE_MFC_DIRS and MSVS_IGNORE_IDE_PATHS are obsoleted and
86 Please note the following important changes since release 1.1.0:
88 -- THE $CHANGED_SOURCES, $CHANGED_TARGETS, $UNCHANGED_SOURCES
89 AND $UNCHANGED_TARGETS VARIABLES WILL BECOME RESERVED
91 A future release (probably 1.3.0) will make the construction
92 variable names $CHANGED_SOURCES, $CHANGED_TARGETS,
93 $UNCHANGED_SOURCES and $UNCHANGED_TARGETS into reserved
94 construction variable names controlled by SCons itself (like
95 the current $SOURCE, $TARGETS, etc.).
97 Setting these variable names in the current release will generate
98 a warning but still set the variables. When they become reserved
99 variable names, they will generate a different warning message
100 and attempts to set these variables will be ignored.
102 SCons configurations that happen to use these variable names
103 should be changed to use different variable names, in order
104 to ensure that the configuration continues to work with future
107 -- THE Options OBJECT AND RELATED FUNCTIONS NOW GENERATE WARNINGS
109 Use of the Options object, and related functions BoolOption(),
110 EnumOption(), ListOption(), PackageOption() and PathOption()
111 were announced as deprecated in release 0.98.1. Since then,
112 however, no warning messages were ever implemented for the
113 use of these deprecated functions.
115 By default, release 1.2.0 prints warning messages when these
116 deprecated features are used. Warnings about all deprecated
117 features may be suppressed by using the --warn=no-deprecated
120 $ scons --warn=no-deprecated
122 Or by using the appropriate SetOption() call in any SConscript
125 SetOption('warn', 'no-deprecated')
127 You may optionally disable just warnings about the deprecation
128 of the Options object and its related functions as follows:
130 SetOption('warn', 'no-deprecated-options')
132 The current plan is for these warnings to become mandatory
133 (non-suppressible) in release 1.3.0, and for the use of Options
134 and its related functions to generate errors in release 2.0.
136 Please note the following important changes since release 0.98.4:
138 -- scons.bat NOW RETURNS THE REAL SCONS EXIT STATUS
140 The scons.bat script shipped with SCons used to exit with
141 a status of 1 when it detected any failed (non-zero) exit
142 status from the underlying Python execution of SCons itself.
143 The scons.bat script now exits with the actual status
146 -- SCONS NOW WARNS WHEN TRYING TO LINK C++ AND FORTRAN OBJECT FILES
148 Some C++ toolchains do not understand Fortran runtimes and create
149 unpredictable executables when linking C++ and Fortran object
150 files together. SCons now issues a warning if you try to link
151 C++ and Fortran object files into the same executable:
153 scons: warning: Using $CXX to link Fortran and C++ code together.
154 This may generate a buggy executable if the '/usr/bin/gcc'
155 compiler does not know how to deal with Fortran runtimes.
157 The warning may be suppressed with either the --warning=no-link
158 or --warning=no-fortran-cxx-mix command line options, or by
159 adding either of the following lines to a SConscript file:
161 SetOption('warn', 'no-link')
162 SetOption('warn', 'no-fortran-cxx-mix')
164 Please note the following important changes since release 0.98:
166 -- SCONS NO LONGER SETS THE GNU TOOLCHAIN -fPIC FLAG IN $SHCXXFLAGS
168 The GNU toolchain support in previous versions of SCons would
169 add the -fPIC flag to the $SHCXXFLAGS construction variable.
170 The -fPIC flag has been now been removed from the default
171 $SHCXXFLAGS setting. Instead, the $SHCXXCOM construction variable
172 (the default SCons command line for compiling shared objects
173 from C++ source files) has been changed to add the $SHCCFLAGS
174 variable, which contains the -fPIC flag.
176 This change was made in order to make the behavior of the default
177 C++ compilation line including $SHCCFLAGS consistent with the
178 default C compilation line including $CCFLAGS.
180 This change should have no impact on configurations that use
181 the default $SHCXXCOM command line. It may have an impact on
182 configurations that were using the default $SHCXXFLAGS value
183 *without* the $SHCCFLAGS variable to get the -fPIC flag into a
184 custom command line. You can fix these by adding the $SHCCFLAGS
185 to the custom command line.
187 Adding $SHCCFLAGS is backwards compatible with older SCons
188 releases, although it might cause the -fPIC flag to be repeated
189 on the command line if you execute it on an older version of
190 SCons that sets -fPIC in both the $SHCCLAFGS and $SHCXXFLAGS
191 variables. Duplicating the -fPIC flag on the g++ command line
192 will not cause any compilation problems, but the change to the
193 command line may cause SCons to rebuild object files.
195 -- FORTRAN NOW COMPILES .f FILES WITH gfortran BY DEFAULT
197 The Fortran Tool modules have had a major overhaul with the intent
198 of making them work as-is for most configurations. In general,
199 most configurations that use default settings should not see
200 any noticeable difference.
202 One configuration that has changed is if you have both a gfortran
203 and g77 compiler installed. In this case, previous versions of
204 SCons would, by default, use g77 by default to compile files with
205 a .f suffix, while SCons 0.98.1 will use the gfortran compiler
206 by default. The old behavior may be preserved by explicitly
207 initializing construction environments with the 'g77' Tool module:
209 env = Environment(tools = ['g77', 'default'])
211 The above code is backwards compatible to older versions of SCons.
213 If you notice any other changes in the behavior of default
214 Fortran support, please let us know so we can document them in
215 these release notes for other users.
217 Please note the following important changes since release 0.97.0d20071212:
219 -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.2 IS NOW DEPRECATED
221 SCons now prints the following warning when it is run by any
222 Python 1.5, 2.0 or 2.1 release or sub-release:
224 scons: warning: Support for pre-2.2 Python (VERSION) is deprecated.
225 If this will cause hardship, contact dev@scons.tigris.org.
227 You may disable all warnings about deprecated features by adding
228 the option "--warn=no-deprecated" to the command line or to the
229 $SCONSFLAGS environment variable:
231 $ scons --warn=no-deprecated
233 Using '--warn=no-deprecated' is compatible with earlier versions
236 You may also, as of this version of SCons, disable all warnings
237 about deprecated features by adding the following to any
240 SetOption('warn', 'no-deprecated')
242 You may disable only the specific warning about running under
243 a deprecated Python version by adding the following to any
246 SetOption('warn', 'no-python-version')
248 The warning may also be suppressed on the command line:
250 $ scons --warn=no-python-version
252 Or by specifying the --warn=no-python-version option in the
253 $SCONSFLAGS environment variable.
255 Using SetOption('warn', ...), and the 'no-python-version'
256 command-line option for suppressing this specific warning,
257 are *not* backwards-compatible to earlier versions of SCons.
259 -- THE env.Copy() METHOD IS NOW OFFICIALLY DEPRECATED
261 The env.Copy() method is now officially deprecated and will
262 be removed in a future release. Using the env.Copy() method
263 now generates the following message:
265 scons: warning: The env.Copy() method is deprecated; use the env.Clone() method instead.
267 You may disable all warnings about deprecated features by adding
268 the option "--warn=no-deprecated" to the command line or to the
269 $SCONSFLAGS environment variable:
271 $ scons --warn=no-deprecated
273 Using '--warn=no-deprecated' is compatible with earlier versions
276 You may also, as of this version of SCons, disable all warnings
277 about deprecated features by adding the following to any
280 SetOption('warn', 'no-deprecated')
282 You may disable only the specific warning about the deprecated
283 env.Copy() method by adding the following to any SConscript
286 SetOption('warn', 'no-deprecated-copy')
288 The warning may also be suppressed on the command line:
290 $ scons --warn=no-deprecated-copy
292 Or by specifying the --warn=no-deprecated-copy option in the
293 $SCONSFLAGS environment variable.
295 Using SetOption('warn', ...), and the 'no-deprecated-copy'
296 command-line option for suppressing this specific warning,
297 are *not* backwards-compatible to earlier versions of SCons.
299 -- THE --debug=dtree, --debug=stree AND --debug=tree OPTIONS ARE DEPRECATED
301 The --debug=dtree, --debug=stree and --debug=tree methods
302 are now officially deprecated and will be removed in a
303 future release. Using these options now generate a warning
304 message recommending use of the --tree=derived, --tree=all,status
305 and --tree=all options, respectively.
307 You may disable these warnings, and all warnings about
308 deprecated features, by adding the option "--warn=no-deprecated"
309 to the command line or to the $SCONSFLAGS environment
312 $ scons --warn=no-deprecated
314 Using '--warn=no-deprecated' is compatible with earlier versions
317 -- THE TargetSignatures() AND SourceSignatures() FUNCTIONS ARE DEPRECATED
319 The TargetSignatures() and SourceSignatures() functions,
320 and their corresponding env.TargetSignatures() and
321 env.SourceSignatures() methods, are now officially deprecated
322 and will be be removed in a future release. Using ahy of
323 these functions or methods now generates a message
324 similar to the following:
326 scons: warning: The env.TargetSignatures() method is deprecated;
327 convert your build to use the env.Decider() method instead.
329 You may disable all warnings about deprecated features by adding
330 the option "--warn=no-deprecated" to the command line or to the
331 $SCONSFLAGS environment variable:
333 $ scons --warn=no-deprecated
335 Using '--warn=no-deprecated' is compatible with earlier versions
338 You may also, as of this version of SCons, disable all warnings
339 about deprecated features by adding the following to any
342 SetOption('warn', 'no-deprecated')
344 You may disable only the specific warning about the use of
345 TargetSignatures() or SourceSignatures() by adding the
346 following to any SConscript file:
348 SetOption('warn', 'no-deprecated-target-signatures')
349 SetOption('warn', 'no-deprecated-source-signatures')
351 The warnings may also be suppressed on the command line:
353 $ scons --warn=no-deprecated-target-signatures --warn=no-deprecated-source-signatures
355 Or by specifying these options in the $SCONSFLAGS environment
358 Using SetOption('warn', ...), or the command-line options
359 for suppressing these warnings, is *not* backwards-compatible
360 to earlier versions of SCons.
362 -- File(), Dir() and Entry() NOW RETURN A LIST WHEN THE INPUT IS A SEQUENCE
364 Previously, if these methods were passed a list, the list was
365 substituted and stringified, then passed as a single string to
366 create a File/Dir/Entry Node. This rarely if ever worked with
367 more than one element in the list. They now return a list of
368 Nodes when passed a list.
370 One case that works differently now is a passing in a
371 single-element sequence; that formerly was stringified
372 (returning its only element) and then a single Node would be
373 returned. Now a single-element list containing the Node will
374 be returned, for consistency.
376 -- THE env.subst() METHOD NOW RETURNS A LIST WHEN THE INPUT IS A SEQUENCE
378 The env.subst() method now returns a list with the elements
379 expanded when given a list as input. Previously, the env.subst()
380 method would always turn its result into a string.
382 This behavior was changed because it interfered with being able
383 to include things like lists within the expansion of variables
384 like $CPPPATH and then have SCons understand that the elements
385 of the "internal" lists still needed to be treated separately.
386 This would cause a $CPPPATH list like ['subdir1', 'subdir']
387 to show up in a command line as "-Isubdir1 subdir".
389 -- THE Jar() BUILDER NOW USES THE Java() BUILDER CLASSDIR BY DEFAULT
391 By default, the Jar() Builder will now use the class directory
392 specified when the Java() builder is called. So the following
395 classes = env.Java('classes', 'src')
396 env.Jar('out.jar', classes)
398 Will cause "-C classes" to be passed the "jar" command invocation,
399 and the Java classes in the "out.jar" file will not be prefixed
402 Explicitly setting the $JARCHDIR variable overrides this default
403 behavior. The old behavior of not passing any -C option to the
404 "jar" command can be preserved by explicitly setting $JARCHDIR
407 env = Environment(JARCHDIR = None)
409 The above setting is compatible with older versions of SCons.
411 Please note the following important changes since release 0.97.0d20070918:
413 -- SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS
414 ON OPEN FILE HANDLES TO CREATED PROCESSES
416 On Windows systems, SCons now redefines the Python open()
417 and file() functions so that, if the Python Win32 extensions
418 are available, the file handles for any opened files will *not*
419 be inherited by subprocesses, such as the spawned compilers and
420 other tools invoked to build the software.
422 This prevents certain race conditions where a file handle for
423 a file opened by Python (either in a Python function action,
424 or directly in a SConscript file) could be inherited and help
425 open by a subprocess, interfering with the ability of other
426 processes to create or modify the file.
428 In general, this should not cause problems for the vast majority
429 of configurations. The only time this would be a problem would be
430 in the unlikely event that a process spawned by SCons specifically
431 *expected* to use an inherited file handle opened by SCons.
433 If the Python Win32 extensions are not installed or are an
434 earlier version that does not have the ability to disable file
435 handle inheritance, SCons will print a warning message when the
436 -j option is used. The warning message may be suppressed by
437 specifying --warn=no-parallel-support.
439 Please note the following important changes since release 0.97.0d20070809:
441 -- "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR
443 The default behavior of SCons is now to use the MD5 checksum of
444 all file contents to decide if any files have changed and should
445 cause rebuilds of their source files. This means that SCons may
446 decide not to rebuild "downstream" targets if a a given input
447 file is rebuilt to the exact same contents as the last time.
448 The old behavior may preserved by explicity specifying:
450 TargetSignatures("build")
452 In any of your SConscript files.
454 -- TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM
456 For all targets built by calling external commands (such as a
457 compiler or other utility), SCons now adds an implicit dependency
458 on the command(s) used to build the target.
460 This will cause rebuilds of all targets built by external commands
461 when running SCons in a tree built by previous version of SCons,
462 in order to update the recorded signatures.
464 The old behavior of not having targets depend on the external
465 commands that build them can be preserved by setting a new
466 $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a
469 env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0)
471 or by adding Ignore() calls for any targets where the behavior
474 Ignore('/usr/bin/gcc', 'foo.o')
476 Both of these settings are compatible with older versions
479 -- CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS
481 If you change the SourceSignature() value from 'timestamp' to
482 'MD5', SCons will now rebuild targets that were already up-to-date
483 with respect to their source files.
485 This will happen because SCons did not record the content
486 signatures of the input source files when the target was last
487 built--it only recorded the timestamps--and it must record them
488 to make sure the signature information is correct. However,
489 the content of source files may have changed since the last
490 timestamp build was performed, and SCons would not have any way to
491 verify that. (It would have had to open up the file and record
492 a content signature, which is one of the things you're trying to
493 avoid by specifying use of timestamps....) So in order to make
494 sure the built targets reflect the contents of the source files,
495 the targets must be rebuilt.
497 Change the SourceSignature() value from 'MD5' to 'timestamp'
498 should correctly not rebuild target files, because the timestamp
499 of the files is always recorded.
501 In previous versions of SCons, changing the SourceSignature()
502 value would lead to unpredictable behavior, usually including
505 -- THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY
507 The Return() function now immediately stops processing the
508 SConscript file in which it appears and returns the values of the
509 variables named in its arguments. It used to continue processing
510 the rest of the SConscript file, and then return the values of the
511 specified variables at the point the Return() function was called.
513 The old behavior may be requested by adding a "stop=False"
514 keyword argument to the Return() call:
516 Return('value', stop=False)
518 The "stop=" keyword argument is *not* compatible with SCons
519 versions 0.97.0d20070809 or earlier.
521 Please note the following important changes since release 0.97:
523 -- env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS
525 The env.CacheDir() method now only causes derived files to be
526 retrieved from the specified cache directory for targets built
527 with the specified specified construction environment ("env").
529 Previously, any call to env.CacheDir() or CacheDir() would modify
530 a global setting and cause all built targets to be retrieved
531 from the specified cache directory. This behavior was changed so
532 that env.CacheDir() would be consistent with other construction
533 environment methods, which only affect targets built with the
534 specified construction environment.
536 The old behavior of changing the global behavior may be preserved
537 by changing any env.CacheDir() calls to:
539 CacheDir('/path/to/cache/directory')
541 The above change is backwards-compatible and works in all earlier
542 versions of SCons that support CacheDir().
544 -- INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED
546 The interpretation of source arguments (files) without suffixes
547 has changed in one specific configuration.
549 Previously, if a Builder had a src_suffix specified (indicating
550 that source files without suffixes should have that suffix
551 appended), the suffix would only be applied to suffix-less source
552 arguments if the Builder did *not* have one or more attached
553 source Builders (that is, the Builder was not a "multi-stage"
554 Builder). So in the following configuration:
556 build_foo = Builder(src_suffix = '.foo')
557 build_bar = Builder(src_suffix = '.bar',
558 src_builder = build_bar)
560 env = Environment(BUILDERS = {
565 env.Foo('tgt1', 'src1')
566 env.Bar('tgt2', 'src2')
568 SCons would have expected to find a source file 'src1.foo' for the
569 env.Foo() call, but a source file 'src2' for the env.Bar() call.
571 This behavior has now been made consistent, so that the two
572 above calls would expect source files named 'src1.foo' and
573 'src2.bar', respectively.
575 Note that, if genuinely desired, the old behavior of building
576 from a source file without a suffix at all (when the Builder has
577 a src_suffix *and* a src_builder) can be specified explicity by
578 turning the string into a File Node directly:
580 env.Bar('tgt2', File('src2'))
582 The above use of File() is backwards-compatible and will work
583 on earlier versions of SCons.
585 -- THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED
587 On Solaris systems, SCons now adds the "/opt/SUNWspro/bin"
588 directory to the default execution $PATH variable before the
589 "/usr/ccs/bin" directory. This was done to reflect the fact
590 that /opt/SUNWspro/ is the default for SUN tools, but it may
591 cause a different compiler to be used if you have compilers
592 installed in both directories.
594 -- GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1"
596 When generating a "config.h" file, SCons now defines values that
597 record the existence of a feature with a "1" value:
599 #define HAVE_FEATURE 1
601 Instead of printing the line without a "1", as it used to:
605 This should not cause any problems in the normal use of "#ifdef
606 HAVE_{FEATURE}" statements interpreted by a C preprocessor, but
607 might cause a compatibility issue if a script or other utility
608 looks for an exact match of the previous text.
610 Please note the following planned, future changes:
612 -- THE Options OBJECT AND RELATED FUNCTIONS WILL BE DEPRECATED
614 The Options object is being replaced by a new Variables
615 object, which uses a new Variables.AddVariable() method
616 where the previous interface used Options.AddOptions().
618 Similarly, the following utility functions are being replaced
619 by the following similarly-named functions:
621 BoolOption() BoolVariable()
622 EnumOption() EnumVariable()
623 ListOption() ListVariable()
624 PackageOption() PackageVariable()
625 PathOption() PathVariable()
627 And also related, the options= keyword argument when creating
628 construction environments with the Environment() functions is
629 being replaced with a variables= keyword argument.
631 In some future release a deprecation warning will be added to
632 existing uses of the Options object, its methods, the above
633 utility functions, and the options= keyword argument of the
634 Environment() function. At some point after the deprecation
635 warning is added, the Options object, related functions and
636 options= keyword argument will be removed entirely.
638 You can prepare for this by changing all your uses of the Options
639 object and related functions to the Variables object and the new
640 function names, and changing any uses of the options= keyword
641 argument to variables=.
643 NOTE: CONVERTING TO USING THE NEW Variables OBJECT OR THE
644 RELATED *Variable() FUNCTIONS, OR USING THE NEW variable=
645 KEYWORD ARGUMENT, IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF
646 SCons BEFORE 0.98. YOUR SConscript FILES WILL NOT WORK ON
647 EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE.
649 If you change SConscript files in software that you make available
650 for download or otherwise distribute, other users may try to
651 build your software with an earlier version of SCons that does
652 not have the Variables object or related *Variable() functions.
653 We recommend preparing for this in one of two ways:
655 -- Make your SConscript files backwards-compatible by
656 modifying your calls with Python try:-except: blocks
660 vars = Variables('custom.py', ARGUMENTS)
662 BoolVariable('WARNINGS', 'cmopile with -Wall', 1),
663 EnumVariable('DEBUG', 'debug version', 'no'
664 allowed_values=('yes', 'no', 'full'),
665 map={}, ignorecase=0),
666 ListVariable('SHAREDLIBS',
667 'libraries to build shared',
669 names = list_of_libs),
670 PackageVariable('X11',
673 PathVariable('QTDIR', 'root of Qt', qtdir),
676 vars = Options('custom.py', ARGUMENTS)
678 BoolOption('WARNINGS', 'cmopile with -Wall', 1),
679 EnumOption('DEBUG', 'debug version', 'no'
680 allowed_values=('yes', 'no', 'full'),
681 map={}, ignorecase=0),
682 ListOption('SHAREDLIBS',
683 'libraries to build shared',
685 names = list_of_libs),
689 PathOption('QTDIR', 'root of Qt', qtdir),
692 Additionally, you can check for availability of the new
693 variables= keyword argument as follows:
696 env = Environment(variables=vars)
698 env = Environment(options=vars)
700 (Note that we plan to maintain the existing Options object
701 name for some time, to ensure backwards compatibility,
702 so in practice it may be easier to just continue to use
703 the old name until you're reasonably sure you won't have
704 people trying to build your software with versions of
705 SCons earlier than 0.98.1.)
707 -- Use the EnsureSConsVersion() function to provide a
708 descriptive error message if your SConscript files
709 are executed by an earlier version of SCons:
711 EnsureSConsVersion(0, 98, 1)
713 -- THE BuildDir() METHOD AND FUNCTION WILL BE DEPRECATED
715 The env.BuildDir() method and BuildDir() function are being
716 replaced by the new env.VariantDir() method and VariantDir()
719 In some future release a deprecation warning will be added
720 to existing uses of the env.BuildDir() method and BuildDir()
721 function. At some point after the deprecation warning, the
722 env.Builder() method and BuildDir() function will either
723 be removed entirely or have their behavior changed.
725 You can prepare for this by changing all your uses of the
726 env.BuildDir() method to env.VariantDir() and uses of the
727 global BuildDir() function to VariantDir(). If you use a
728 named keyword argument of "build_dir" when calling
729 env.BuildDir() or BuildDir():
731 env.BuildDir(build_dir='opt', src_dir='src')
733 The keyword must be changed to "variant_dir":
735 env.VariantDir(variant_dir='opt', src_dir='src')
737 NOTE: CHANGING USES OF env.BuildDir() AND BuildDir() to
738 env.VariantDir() AND VariantDir() IS NOT BACKWARDS COMPATIBLE
739 TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES
740 WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING
743 If you change SConscript files in software that you make
744 available for download or otherwise distribute, other users
745 may try to build your software with an earlier version of
746 SCons that does not have the env.VariantDir() method or
747 VariantDir() fnction. We recommend preparing for this in
750 -- Make your SConscript files backwards-compatible by
751 including the following code near the beginning of your
752 top-level SConstruct file:
754 import SCons.Environment
756 SCons.Environment.Environment.VariantDir
757 except AttributeError:
758 SCons.Environment.Environment.VariantDir = \
759 SCons.Environment.Environment.BuildDir
761 -- Use the EnsureSConsVersion() function to provide a
762 descriptive error message if your SConscript files
763 are executed by an earlier version of SCons:
765 EnsureSConsVersion(0, 98)
767 -- THE SConscript() "build_dir" KEYWORD ARGUMENT WILL BE DEPRECATED
769 The "build_dir" keyword argument of the SConscript function
770 and env.SConscript() method are being replaced by a new
771 "variant_dir" keyword argument.
773 In some future release a deprecation warning will be added
774 to existing uses of the SConscript()/env.SConscript()
775 "build_dir" keyword argument. At some point after the
776 deprecation warning, support for this keyword argument will
779 You can prepare for this by changing all your uses of the
780 SConscript()/env.SConscript() 'build_dir" keyword argument:
782 SConscript('src/SConscript', build_dir='opt')
784 To use the new "variant_dir" keyword argument:
786 SConscript('src/SConscript', variant_dir='opt')
788 NOTE: USING THE NEW "variant_dir" KEYWORD IS NOT BACKWARDS
789 COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript
790 FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER
793 If you change SConscript files in software that you make
794 available for download or otherwise distribute, other users
795 may try to build your software with an earlier version of
796 SCons that does not support the "variant_dir" keyword.
798 If you can insist that users use a recent version of SCons
799 that supports "variant_dir", we recommend using the
800 EnsureSConsVersion() function to provide a descriptive error
801 message if your SConscript files are executed by an earlier
804 EnsureSConsVersion(0, 98)
806 If you want to make sure that your SConscript files will
807 still work with earlier versions of SCons, then your best
808 bet is to continue to use the "build_dir" keyword until the
809 support is removed (which, in all likelihood, won't happen
810 for quite some time).
812 -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
814 Several internal variable names in SCons.Defaults for various
815 pre-made default Scanner objects have been deprecated and will
816 be removed in a future revision. In their place are several new
817 global variable names that are now part of the publicly-supported
820 NEW NAME DEPRECATED NAME
821 -------- ----------------------------
822 CScanner SCons.Defaults.CScan
823 DSCanner SCons.Defaults.DScan
824 SourceFileScanner SCons.Defaults.ObjSourceScan
825 ProgramScanner SCons.Defaults.ProgScan
827 Of these, only ObjSourceScan was probably used at all, to add
828 new mappings of file suffixes to other scanners for use by the
829 Object() Builder. This should now be done as follows:
831 SourceFileScanner.add_scanner('.x', XScanner)
833 -- THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY
835 The env.Copy() method (to make a copy of a construction
836 environment) is being replaced by the env.Clone() method.
838 As of SCons 0.98, a deprecation warning has been added to
839 current uses of the env.Copy() method. At some point in
840 the future, the env.Copy() method will either be removed
841 entirely or have its behavior changed.
843 You can prepare for this by changing all your uses of env.Copy()
844 to env.Clone(), which has the exact same calling arguments.
846 NOTE: CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE
847 YOUR SConscript FILES NOT WORK ON VERSIONS OF SCons BEFORE
850 If you change SConscript files in software that you make
851 available for download or otherwise distribute, other users
852 may try to build your software with an earlier version of
853 SCons that does not have the env.Clone() method. We recommend
854 preparing for this in one of two ways:
856 -- Make your SConscript files backwards-compatible by
857 including the following code near the beginning of your
858 top-level SConstruct file:
860 import SCons.Environment
862 SCons.Environment.Environment.Clone
863 except AttributeError:
864 SCons.Environment.Environment.Clone = \
865 SCons.Environment.Environment.Copy
867 -- Use the EnsureSConsVersion() function to provide a
868 descriptive error message if your SConscript files
869 are executed by an earlier version of SCons:
871 EnsureSConsVersion(0, 96, 93)
873 -- THE CheckLib Configure TEST WILL CHANGE BEHAVIOR
875 The CheckLib() Configure test appends the lib(s) to the
876 Environment's LIBS list in 1.3 and earlier. In 1.3 there is a
877 new CheckLib argument, append, which defaults to True to
878 preserve the old behavior. In a future release, append will
879 be changed to default to False, to conform with autoconf and
880 user expectations, since it is usually used to build up
881 library lists in a right-to-left way.
885 SCons is developed with an extensive regression test suite, and a
886 rigorous development methodology for continually improving that suite.
887 Because of this, SCons is of sufficient quality that you can use it
890 The interfaces in release 1.0 will *not* be knowingly changed in
891 any new, future 1.x release. If an interface change should ever
892 become necessary due to extraordinary circumstances, the change
893 and an appropriate transition strategy will be documented in these
896 As you use SCons, please heed the following:
898 - Please report any bugs or other problems that you find to our bug
899 tracker at our SourceForge project page:
901 http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
903 We have a reliable bug-fixing methodology already in place and
904 strive to respond to problems relatively quickly.
906 - Documentation is spottier than we'd like. You may need to dive
907 into the source code to figure out how to do something. Asking
908 questions on the scons-users mailing list is also welcome. We
909 will be addressing the documentation in upcoming releases, but
910 would be more than glad to have your assistance in correcting this
913 - The "SCons Design" documentation on the SCons web site is very
914 out of date, as we made significant changes to portions of the
915 interface as we figured out what worked and what didn't during the
916 extensive beta implementation. The "SCons Design" document should
917 be used only for historical purposes, or for just an extremely
918 general understanding of SCons' architectural goals.
920 - There may be performance issues. Improving SCons performance
921 is an ongoing priority. If you still find the performance
922 unacceptable, we would very much like to hear from you and learn
923 more about your configuration so we can optimize the right things.
925 - Error messages don't always exist where they'd be helpful.
926 Please let us know about any errors you ran into that would
927 have benefitted from a (more) descriptive message.
929 KNOWN PROBLEMS IN THIS RELEASE:
931 For a complete list of known problems, consult the SCons Issue Tracker
934 http://scons.tigris.org/project_issues.html
936 - Support for parallel builds (-j) does not work on WIN32 systems
937 prior to *official* Python release 2.2 (not 2.2 pre-releases).
939 Prior to Python 2.2, there is a bug in Python's Win32
940 implementation such that when a thread spawns an external command,
941 it blocks all threads from running. This breaks the SCons
942 multithreading architecture used to support -j builds.
944 We have included a patch file, os_spawnv_fix.diff, that you can
945 use if you you want to fix your version of Python to support
946 parallel builds in SCons.
948 - Again, the "SCons Design" documentation on the SCons web site is
949 out of date. Take what you read there with a grain of salt.
951 - On Win32 systems, you must put a space between the redirection
952 characters < and >, and the specified files (or construction
953 variable expansions):
955 command < $SOURCE > $TARGET
957 If you don't supply a space (for example, "<$SOURCE"), SCons will
958 not recognize the redirection.
960 - MSVC .res files are not rebuilt when icons change.
962 - The -c option does not clean up .sconsign files or directories
963 created as part of the build, and also does not clean up
964 SideEffect files (for example, Visual Studio .pdb files).
966 - When using multiple Repositories, changing the name of an include
967 file can cause an old version of the file to be used.
969 - There is currently no way to force use of a relative path (../*)
970 for directories outside the top-level SConstruct file.
972 - The Jar() Builder will, on its second or subsequent invocation,
973 package up the .sconsign files that SCons uses to track signatures.
974 You can work around this by using the SConsignFile() function
975 to collect all of the .sconsign information into a single file
976 outside of the directory being packaged by Jar().
978 - SCons does not currently have a way to detect that an intermediate
979 file has been corrupted from outside and should be rebuilt.
981 - Unicode characters in path names do not work in all circumstances.
983 - SCons does not currently automatically check out SConstruct or
984 SConscript files from SCCS, RCS or BitKeeper.
986 - No support yet for the following planned command-line options:
988 -d -e -l --list-actions --list-derived --list-where
989 -o --override -p -r -R -w --write-filenames
990 -W --warn-undefined-variables
994 Thank you for your interest, and please let us know how we can help
995 improve SCons for your needs.
998 knight at baldmt dot com
999 http://www.baldmt.com/~knight/
1001 With plenty of help from the SCons Development team: