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 and 2.1.
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 Please note the following important changes since release 1.1.0:
85 -- THE $CHANGED_SOURCES, $CHANGED_TARGETS, $UNCHANGED_SOURCES
86 AND $UNCHANGED_TARGETS VARIABLES WILL BECOME RESERVED
88 A future release (probably 1.3.0) will make the construction
89 variable names $CHANGED_SOURCES, $CHANGED_TARGETS,
90 $UNCHANGED_SOURCES and $UNCHANGED_TARGETS into reserved
91 construction variable names controlled by SCons itself (like
92 the current $SOURCE, $TARGETS, etc.).
94 Setting these variable names in the current release will generate
95 a warning but still set the variables. When they become reserved
96 variable names, they will generate a different warning message
97 and attempts to set these variables will be ignored.
99 SCons configurations that happen to use these variable names
100 should be changed to use different variable names, in order
101 to ensure that the configuration continues to work with future
104 -- THE Options OBJECT AND RELATED FUNCTIONS NOW GENERATE WARNINGS
106 Use of the Options object, and related functions BoolOption(),
107 EnumOption(), ListOption(), PackageOption() and PathOption()
108 were announced as deprecated in release 0.98.1. Since then,
109 however, no warning messages were ever implemented for the
110 use of these deprecated functions.
112 By default, release 1.2.0 prints warning messages when these
113 deprecated features are used. Warnings about all deprecated
114 features may be suppressed by using the --warn=no-deprecated
117 $ scons --warn=no-deprecated
119 Or by using the appropriate SetOption() call in any SConscript
122 SetOption('warn', 'no-deprecated')
124 You may optionally disable just warnings about the deprecation
125 of the Options object and its related functions as follows:
127 SetOption('warn', 'no-deprecated-options')
129 The current plan is for these warnings to become mandatory
130 (non-suppressible) in release 1.3.0, and for the use of Options
131 and its related functions to generate errors in release 2.0.
133 Please note the following important changes since release 0.98.4:
135 -- scons.bat NOW RETURNS THE REAL SCONS EXIT STATUS
137 The scons.bat script shipped with SCons used to exit with
138 a status of 1 when it detected any failed (non-zero) exit
139 status from the underlying Python execution of SCons itself.
140 The scons.bat script now exits with the actual status
143 -- SCONS NOW WARNS WHEN TRYING TO LINK C++ AND FORTRAN OBJECT FILES
145 Some C++ toolchains do not understand Fortran runtimes and create
146 unpredictable executables when linking C++ and Fortran object
147 files together. SCons now issues a warning if you try to link
148 C++ and Fortran object files into the same executable:
150 scons: warning: Using $CXX to link Fortran and C++ code together.
151 This may generate a buggy executable if the '/usr/bin/gcc'
152 compiler does not know how to deal with Fortran runtimes.
154 The warning may be suppressed with either the --warning=no-link
155 or --warning=no-fortran-cxx-mix command line options, or by
156 adding either of the following lines to a SConscript file:
158 SetOption('warn', 'no-link')
159 SetOption('warn', 'no-fortran-cxx-mix')
161 Please note the following important changes since release 0.98:
163 -- SCONS NO LONGER SETS THE GNU TOOLCHAIN -fPIC FLAG IN $SHCXXFLAGS
165 The GNU toolchain support in previous versions of SCons would
166 add the -fPIC flag to the $SHCXXFLAGS construction variable.
167 The -fPIC flag has been now been removed from the default
168 $SHCXXFLAGS setting. Instead, the $SHCXXCOM construction variable
169 (the default SCons command line for compiling shared objects
170 from C++ source files) has been changed to add the $SHCCFLAGS
171 variable, which contains the -fPIC flag.
173 This change was made in order to make the behavior of the default
174 C++ compilation line including $SHCCFLAGS consistent with the
175 default C compilation line including $CCFLAGS.
177 This change should have no impact on configurations that use
178 the default $SHCXXCOM command line. It may have an impact on
179 configurations that were using the default $SHCXXFLAGS value
180 *without* the $SHCCFLAGS variable to get the -fPIC flag into a
181 custom command line. You can fix these by adding the $SHCCFLAGS
182 to the custom command line.
184 Adding $SHCCFLAGS is backwards compatible with older SCons
185 releases, although it might cause the -fPIC flag to be repeated
186 on the command line if you execute it on an older version of
187 SCons that sets -fPIC in both the $SHCCLAFGS and $SHCXXFLAGS
188 variables. Duplicating the -fPIC flag on the g++ command line
189 will not cause any compilation problems, but the change to the
190 command line may cause SCons to rebuild object files.
192 -- FORTRAN NOW COMPILES .f FILES WITH gfortran BY DEFAULT
194 The Fortran Tool modules have had a major overhaul with the intent
195 of making them work as-is for most configurations. In general,
196 most configurations that use default settings should not see
197 any noticeable difference.
199 One configuration that has changed is if you have both a gfortran
200 and g77 compiler installed. In this case, previous versions of
201 SCons would, by default, use g77 by default to compile files with
202 a .f suffix, while SCons 0.98.1 will use the gfortran compiler
203 by default. The old behavior may be preserved by explicitly
204 initializing construction environments with the 'g77' Tool module:
206 env = Environment(tools = ['g77', 'default'])
208 The above code is backwards compatible to older versions of SCons.
210 If you notice any other changes in the behavior of default
211 Fortran support, please let us know so we can document them in
212 these release notes for other users.
214 Please note the following important changes since release 0.97.0d20071212:
216 -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.2 IS NOW DEPRECATED
218 SCons now prints the following warning when it is run by any
219 Python 1.5, 2.0 or 2.1 release or sub-release:
221 scons: warning: Support for pre-2.2 Python (VERSION) is deprecated.
222 If this will cause hardship, contact dev@scons.tigris.org.
224 You may disable all warnings about deprecated features by adding
225 the option "--warn=no-deprecated" to the command line or to the
226 $SCONSFLAGS environment variable:
228 $ scons --warn=no-deprecated
230 Using '--warn=no-deprecated' is compatible with earlier versions
233 You may also, as of this version of SCons, disable all warnings
234 about deprecated features by adding the following to any
237 SetOption('warn', 'no-deprecated')
239 You may disable only the specific warning about running under
240 a deprecated Python version by adding the following to any
243 SetOption('warn', 'no-python-version')
245 The warning may also be suppressed on the command line:
247 $ scons --warn=no-python-version
249 Or by specifying the --warn=no-python-version option in the
250 $SCONSFLAGS environment variable.
252 Using SetOption('warn', ...), and the 'no-python-version'
253 command-line option for suppressing this specific warning,
254 are *not* backwards-compatible to earlier versions of SCons.
256 -- THE env.Copy() METHOD IS NOW OFFICIALLY DEPRECATED
258 The env.Copy() method is now officially deprecated and will
259 be removed in a future release. Using the env.Copy() method
260 now generates the following message:
262 scons: warning: The env.Copy() method is deprecated; use the env.Clone() method instead.
264 You may disable all warnings about deprecated features by adding
265 the option "--warn=no-deprecated" to the command line or to the
266 $SCONSFLAGS environment variable:
268 $ scons --warn=no-deprecated
270 Using '--warn=no-deprecated' is compatible with earlier versions
273 You may also, as of this version of SCons, disable all warnings
274 about deprecated features by adding the following to any
277 SetOption('warn', 'no-deprecated')
279 You may disable only the specific warning about the deprecated
280 env.Copy() method by adding the following to any SConscript
283 SetOption('warn', 'no-deprecated-copy')
285 The warning may also be suppressed on the command line:
287 $ scons --warn=no-deprecated-copy
289 Or by specifying the --warn=no-deprecated-copy option in the
290 $SCONSFLAGS environment variable.
292 Using SetOption('warn', ...), and the 'no-deprecated-copy'
293 command-line option for suppressing this specific warning,
294 are *not* backwards-compatible to earlier versions of SCons.
296 -- THE --debug=dtree, --debug=stree AND --debug=tree OPTIONS ARE DEPRECATED
298 The --debug=dtree, --debug=stree and --debug=tree methods
299 are now officially deprecated and will be removed in a
300 future release. Using these options now generate a warning
301 message recommending use of the --tree=derived, --tree=all,status
302 and --tree=all options, respectively.
304 You may disable these warnings, and all warnings about
305 deprecated features, by adding the option "--warn=no-deprecated"
306 to the command line or to the $SCONSFLAGS environment
309 $ scons --warn=no-deprecated
311 Using '--warn=no-deprecated' is compatible with earlier versions
314 -- THE TargetSignatures() AND SourceSignatures() FUNCTIONS ARE DEPRECATED
316 The TargetSignatures() and SourceSignatures() functions,
317 and their corresponding env.TargetSignatures() and
318 env.SourceSignatures() methods, are now officially deprecated
319 and will be be removed in a future release. Using ahy of
320 these functions or methods now generates a message
321 similar to the following:
323 scons: warning: The env.TargetSignatures() method is deprecated;
324 convert your build to use the env.Decider() method instead.
326 You may disable all warnings about deprecated features by adding
327 the option "--warn=no-deprecated" to the command line or to the
328 $SCONSFLAGS environment variable:
330 $ scons --warn=no-deprecated
332 Using '--warn=no-deprecated' is compatible with earlier versions
335 You may also, as of this version of SCons, disable all warnings
336 about deprecated features by adding the following to any
339 SetOption('warn', 'no-deprecated')
341 You may disable only the specific warning about the use of
342 TargetSignatures() or SourceSignatures() by adding the
343 following to any SConscript file:
345 SetOption('warn', 'no-deprecated-target-signatures')
346 SetOption('warn', 'no-deprecated-source-signatures')
348 The warnings may also be suppressed on the command line:
350 $ scons --warn=no-deprecated-target-signatures --warn=no-deprecated-source-signatures
352 Or by specifying these options in the $SCONSFLAGS environment
355 Using SetOption('warn', ...), or the command-line options
356 for suppressing these warnings, is *not* backwards-compatible
357 to earlier versions of SCons.
359 -- File(), Dir() and Entry() NOW RETURN A LIST WHEN THE INPUT IS A SEQUENCE
361 Previously, if these methods were passed a list, the list was
362 substituted and stringified, then passed as a single string to
363 create a File/Dir/Entry Node. This rarely if ever worked with
364 more than one element in the list. They now return a list of
365 Nodes when passed a list.
367 One case that works differently now is a passing in a
368 single-element sequence; that formerly was stringified
369 (returning its only element) and then a single Node would be
370 returned. Now a single-element list containing the Node will
371 be returned, for consistency.
373 -- THE env.subst() METHOD NOW RETURNS A LIST WHEN THE INPUT IS A SEQUENCE
375 The env.subst() method now returns a list with the elements
376 expanded when given a list as input. Previously, the env.subst()
377 method would always turn its result into a string.
379 This behavior was changed because it interfered with being able
380 to include things like lists within the expansion of variables
381 like $CPPPATH and then have SCons understand that the elements
382 of the "internal" lists still needed to be treated separately.
383 This would cause a $CPPPATH list like ['subdir1', 'subdir']
384 to show up in a command line as "-Isubdir1 subdir".
386 -- THE Jar() BUILDER NOW USES THE Java() BUILDER CLASSDIR BY DEFAULT
388 By default, the Jar() Builder will now use the class directory
389 specified when the Java() builder is called. So the following
392 classes = env.Java('classes', 'src')
393 env.Jar('out.jar', classes)
395 Will cause "-C classes" to be passed the "jar" command invocation,
396 and the Java classes in the "out.jar" file will not be prefixed
399 Explicitly setting the $JARCHDIR variable overrides this default
400 behavior. The old behavior of not passing any -C option to the
401 "jar" command can be preserved by explicitly setting $JARCHDIR
404 env = Environment(JARCHDIR = None)
406 The above setting is compatible with older versions of SCons.
408 Please note the following important changes since release 0.97.0d20070918:
410 -- SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS
411 ON OPEN FILE HANDLES TO CREATED PROCESSES
413 On Windows systems, SCons now redefines the Python open()
414 and file() functions so that, if the Python Win32 extensions
415 are available, the file handles for any opened files will *not*
416 be inherited by subprocesses, such as the spawned compilers and
417 other tools invoked to build the software.
419 This prevents certain race conditions where a file handle for
420 a file opened by Python (either in a Python function action,
421 or directly in a SConscript file) could be inherited and help
422 open by a subprocess, interfering with the ability of other
423 processes to create or modify the file.
425 In general, this should not cause problems for the vast majority
426 of configurations. The only time this would be a problem would be
427 in the unlikely event that a process spawned by SCons specifically
428 *expected* to use an inherited file handle opened by SCons.
430 If the Python Win32 extensions are not installed or are an
431 earlier version that does not have the ability to disable file
432 handle inheritance, SCons will print a warning message when the
433 -j option is used. The warning message may be suppressed by
434 specifying --warn=no-parallel-support.
436 Please note the following important changes since release 0.97.0d20070809:
438 -- "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR
440 The default behavior of SCons is now to use the MD5 checksum of
441 all file contents to decide if any files have changed and should
442 cause rebuilds of their source files. This means that SCons may
443 decide not to rebuild "downstream" targets if a a given input
444 file is rebuilt to the exact same contents as the last time.
445 The old behavior may preserved by explicity specifying:
447 TargetSignatures("build")
449 In any of your SConscript files.
451 -- TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM
453 For all targets built by calling external commands (such as a
454 compiler or other utility), SCons now adds an implicit dependency
455 on the command(s) used to build the target.
457 This will cause rebuilds of all targets built by external commands
458 when running SCons in a tree built by previous version of SCons,
459 in order to update the recorded signatures.
461 The old behavior of not having targets depend on the external
462 commands that build them can be preserved by setting a new
463 $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a
466 env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0)
468 or by adding Ignore() calls for any targets where the behavior
471 Ignore('/usr/bin/gcc', 'foo.o')
473 Both of these settings are compatible with older versions
476 -- CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS
478 If you change the SourceSignature() value from 'timestamp' to
479 'MD5', SCons will now rebuild targets that were already up-to-date
480 with respect to their source files.
482 This will happen because SCons did not record the content
483 signatures of the input source files when the target was last
484 built--it only recorded the timestamps--and it must record them
485 to make sure the signature information is correct. However,
486 the content of source files may have changed since the last
487 timestamp build was performed, and SCons would not have any way to
488 verify that. (It would have had to open up the file and record
489 a content signature, which is one of the things you're trying to
490 avoid by specifying use of timestamps....) So in order to make
491 sure the built targets reflect the contents of the source files,
492 the targets must be rebuilt.
494 Change the SourceSignature() value from 'MD5' to 'timestamp'
495 should correctly not rebuild target files, because the timestamp
496 of the files is always recorded.
498 In previous versions of SCons, changing the SourceSignature()
499 value would lead to unpredictable behavior, usually including
502 -- THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY
504 The Return() function now immediately stops processing the
505 SConscript file in which it appears and returns the values of the
506 variables named in its arguments. It used to continue processing
507 the rest of the SConscript file, and then return the values of the
508 specified variables at the point the Return() function was called.
510 The old behavior may be requested by adding a "stop=False"
511 keyword argument to the Return() call:
513 Return('value', stop=False)
515 The "stop=" keyword argument is *not* compatible with SCons
516 versions 0.97.0d20070809 or earlier.
518 Please note the following important changes since release 0.97:
520 -- env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS
522 The env.CacheDir() method now only causes derived files to be
523 retrieved from the specified cache directory for targets built
524 with the specified specified construction environment ("env").
526 Previously, any call to env.CacheDir() or CacheDir() would modify
527 a global setting and cause all built targets to be retrieved
528 from the specified cache directory. This behavior was changed so
529 that env.CacheDir() would be consistent with other construction
530 environment methods, which only affect targets built with the
531 specified construction environment.
533 The old behavior of changing the global behavior may be preserved
534 by changing any env.CacheDir() calls to:
536 CacheDir('/path/to/cache/directory')
538 The above change is backwards-compatible and works in all earlier
539 versions of SCons that support CacheDir().
541 -- INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED
543 The interpretation of source arguments (files) without suffixes
544 has changed in one specific configuration.
546 Previously, if a Builder had a src_suffix specified (indicating
547 that source files without suffixes should have that suffix
548 appended), the suffix would only be applied to suffix-less source
549 arguments if the Builder did *not* have one or more attached
550 source Builders (that is, the Builder was not a "multi-stage"
551 Builder). So in the following configuration:
553 build_foo = Builder(src_suffix = '.foo')
554 build_bar = Builder(src_suffix = '.bar',
555 src_builder = build_bar)
557 env = Environment(BUILDERS = {
562 env.Foo('tgt1', 'src1')
563 env.Bar('tgt2', 'src2')
565 SCons would have expected to find a source file 'src1.foo' for the
566 env.Foo() call, but a source file 'src2' for the env.Bar() call.
568 This behavior has now been made consistent, so that the two
569 above calls would expect source files named 'src1.foo' and
570 'src2.bar', respectively.
572 Note that, if genuinely desired, the old behavior of building
573 from a source file without a suffix at all (when the Builder has
574 a src_suffix *and* a src_builder) can be specified explicity by
575 turning the string into a File Node directly:
577 env.Bar('tgt2', File('src2'))
579 The above use of File() is backwards-compatible and will work
580 on earlier versions of SCons.
582 -- THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED
584 On Solaris systems, SCons now adds the "/opt/SUNWspro/bin"
585 directory to the default execution $PATH variable before the
586 "/usr/ccs/bin" directory. This was done to reflect the fact
587 that /opt/SUNWspro/ is the default for SUN tools, but it may
588 cause a different compiler to be used if you have compilers
589 installed in both directories.
591 -- GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1"
593 When generating a "config.h" file, SCons now defines values that
594 record the existence of a feature with a "1" value:
596 #define HAVE_FEATURE 1
598 Instead of printing the line without a "1", as it used to:
602 This should not cause any problems in the normal use of "#ifdef
603 HAVE_{FEATURE}" statements interpreted by a C preprocessor, but
604 might cause a compatibility issue if a script or other utility
605 looks for an exact match of the previous text.
607 Please note the following planned, future changes:
609 -- THE Options OBJECT AND RELATED FUNCTIONS WILL BE DEPRECATED
611 The Options object is being replaced by a new Variables
612 object, which uses a new Variables.AddVariable() method
613 where the previous interface used Options.AddOptions().
615 Similarly, the following utility functions are being replaced
616 by the following similarly-named functions:
618 BoolOption() BoolVariable()
619 EnumOption() EnumVariable()
620 ListOption() ListVariable()
621 PackageOption() PackageVariable()
622 PathOption() PathVariable()
624 And also related, the options= keyword argument when creating
625 construction environments with the Environment() functions is
626 being replaced with a variables= keyword argument.
628 In some future release a deprecation warning will be added to
629 existing uses of the Options object, its methods, the above
630 utility functions, and the options= keyword argument of the
631 Environment() function. At some point after the deprecation
632 warning is added, the Options object, related functions and
633 options= keyword argument will be removed entirely.
635 You can prepare for this by changing all your uses of the Options
636 object and related functions to the Variables object and the new
637 function names, and changing any uses of the options= keyword
638 argument to variables=.
640 NOTE: CONVERTING TO USING THE NEW Variables OBJECT OR THE
641 RELATED *Variable() FUNCTIONS, OR USING THE NEW variable=
642 KEYWORD ARGUMENT, IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF
643 SCons BEFORE 0.98. YOUR SConscript FILES WILL NOT WORK ON
644 EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE.
646 If you change SConscript files in software that you make available
647 for download or otherwise distribute, other users may try to
648 build your software with an earlier version of SCons that does
649 not have the Variables object or related *Variable() functions.
650 We recommend preparing for this in one of two ways:
652 -- Make your SConscript files backwards-compatible by
653 modifying your calls with Python try:-except: blocks
657 vars = Variables('custom.py', ARGUMENTS)
659 BoolVariable('WARNINGS', 'cmopile with -Wall', 1),
660 EnumVariable('DEBUG', 'debug version', 'no'
661 allowed_values=('yes', 'no', 'full'),
662 map={}, ignorecase=0),
663 ListVariable('SHAREDLIBS',
664 'libraries to build shared',
666 names = list_of_libs),
667 PackageVariable('X11',
670 PathVariable('QTDIR', 'root of Qt', qtdir),
673 vars = Options('custom.py', ARGUMENTS)
675 BoolOption('WARNINGS', 'cmopile with -Wall', 1),
676 EnumOption('DEBUG', 'debug version', 'no'
677 allowed_values=('yes', 'no', 'full'),
678 map={}, ignorecase=0),
679 ListOption('SHAREDLIBS',
680 'libraries to build shared',
682 names = list_of_libs),
686 PathOption('QTDIR', 'root of Qt', qtdir),
689 Additionally, you can check for availability of the new
690 variables= keyword argument as follows:
693 env = Environment(variables=vars)
695 env = Environment(options=vars)
697 (Note that we plan to maintain the existing Options object
698 name for some time, to ensure backwards compatibility,
699 so in practice it may be easier to just continue to use
700 the old name until you're reasonably sure you won't have
701 people trying to build your software with versions of
702 SCons earlier than 0.98.1.)
704 -- Use the EnsureSConsVersion() function to provide a
705 descriptive error message if your SConscript files
706 are executed by an earlier version of SCons:
708 EnsureSConsVersion(0, 98, 1)
710 -- THE BuildDir() METHOD AND FUNCTION WILL BE DEPRECATED
712 The env.BuildDir() method and BuildDir() function are being
713 replaced by the new env.VariantDir() method and VariantDir()
716 In some future release a deprecation warning will be added
717 to existing uses of the env.BuildDir() method and BuildDir()
718 function. At some point after the deprecation warning, the
719 env.Builder() method and BuildDir() function will either
720 be removed entirely or have their behavior changed.
722 You can prepare for this by changing all your uses of the
723 env.BuildDir() method to env.VariantDir() and uses of the
724 global BuildDir() function to VariantDir(). If you use a
725 named keyword argument of "build_dir" when calling
726 env.BuildDir() or BuildDir():
728 env.BuildDir(build_dir='opt', src_dir='src')
730 The keyword must be changed to "variant_dir":
732 env.VariantDir(variant_dir='opt', src_dir='src')
734 NOTE: CHANGING USES OF env.BuildDir() AND BuildDir() to
735 env.VariantDir() AND VariantDir() IS NOT BACKWARDS COMPATIBLE
736 TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES
737 WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING
740 If you change SConscript files in software that you make
741 available for download or otherwise distribute, other users
742 may try to build your software with an earlier version of
743 SCons that does not have the env.VariantDir() method or
744 VariantDir() fnction. We recommend preparing for this in
747 -- Make your SConscript files backwards-compatible by
748 including the following code near the beginning of your
749 top-level SConstruct file:
751 import SCons.Environment
753 SCons.Environment.Environment.VariantDir
754 except AttributeError:
755 SCons.Environment.Environment.VariantDir = \
756 SCons.Environment.Environment.BuildDir
758 -- Use the EnsureSConsVersion() function to provide a
759 descriptive error message if your SConscript files
760 are executed by an earlier version of SCons:
762 EnsureSConsVersion(0, 98)
764 -- THE SConscript() "build_dir" KEYWORD ARGUMENT WILL BE DEPRECATED
766 The "build_dir" keyword argument of the SConscript function
767 and env.SConscript() method are being replaced by a new
768 "variant_dir" keyword argument.
770 In some future release a deprecation warning will be added
771 to existing uses of the SConscript()/env.SConscript()
772 "build_dir" keyword argument. At some point after the
773 deprecation warning, support for this keyword argument will
776 You can prepare for this by changing all your uses of the
777 SConscript()/env.SConscript() 'build_dir" keyword argument:
779 SConscript('src/SConscript', build_dir='opt')
781 To use the new "variant_dir" keyword argument:
783 SConscript('src/SConscript', variant_dir='opt')
785 NOTE: USING THE NEW "variant_dir" KEYWORD IS NOT BACKWARDS
786 COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript
787 FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER
790 If you change SConscript files in software that you make
791 available for download or otherwise distribute, other users
792 may try to build your software with an earlier version of
793 SCons that does not support the "variant_dir" keyword.
795 If you can insist that users use a recent version of SCons
796 that supports "variant_dir", we recommend using the
797 EnsureSConsVersion() function to provide a descriptive error
798 message if your SConscript files are executed by an earlier
801 EnsureSConsVersion(0, 98)
803 If you want to make sure that your SConscript files will
804 still work with earlier versions of SCons, then your best
805 bet is to continue to use the "build_dir" keyword until the
806 support is removed (which, in all likelihood, won't happen
807 for quite some time).
809 -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
811 Several internal variable names in SCons.Defaults for various
812 pre-made default Scanner objects have been deprecated and will
813 be removed in a future revision. In their place are several new
814 global variable names that are now part of the publicly-supported
817 NEW NAME DEPRECATED NAME
818 -------- ----------------------------
819 CScanner SCons.Defaults.CScan
820 DSCanner SCons.Defaults.DScan
821 SourceFileScanner SCons.Defaults.ObjSourceScan
822 ProgramScanner SCons.Defaults.ProgScan
824 Of these, only ObjSourceScan was probably used at all, to add
825 new mappings of file suffixes to other scanners for use by the
826 Object() Builder. This should now be done as follows:
828 SourceFileScanner.add_scanner('.x', XScanner)
830 -- THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY
832 The env.Copy() method (to make a copy of a construction
833 environment) is being replaced by the env.Clone() method.
835 As of SCons 0.98, a deprecation warning has been added to
836 current uses of the env.Copy() method. At some point in
837 the future, the env.Copy() method will either be removed
838 entirely or have its behavior changed.
840 You can prepare for this by changing all your uses of env.Copy()
841 to env.Clone(), which has the exact same calling arguments.
843 NOTE: CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE
844 YOUR SConscript FILES NOT WORK ON VERSIONS OF SCons BEFORE
847 If you change SConscript files in software that you make
848 available for download or otherwise distribute, other users
849 may try to build your software with an earlier version of
850 SCons that does not have the env.Clone() method. We recommend
851 preparing for this in one of two ways:
853 -- Make your SConscript files backwards-compatible by
854 including the following code near the beginning of your
855 top-level SConstruct file:
857 import SCons.Environment
859 SCons.Environment.Environment.Clone
860 except AttributeError:
861 SCons.Environment.Environment.Clone = \
862 SCons.Environment.Environment.Copy
864 -- Use the EnsureSConsVersion() function to provide a
865 descriptive error message if your SConscript files
866 are executed by an earlier version of SCons:
868 EnsureSConsVersion(0, 96, 93)
870 -- THE CheckLib Configure TEST WILL CHANGE BEHAVIOR
872 The CheckLib() Configure test appends the lib(s) to the
873 Environment's LIBS list in 1.3 and earlier. In 1.3 there is a
874 new CheckLib argument, append, which defaults to True to
875 preserve the old behavior. In a future release, append will
876 be changed to default to False, to conform with autoconf and
877 user expectations, since it is usually used to build up
878 library lists in a right-to-left way.
882 SCons is developed with an extensive regression test suite, and a
883 rigorous development methodology for continually improving that suite.
884 Because of this, SCons is of sufficient quality that you can use it
887 The interfaces in release 1.0 will *not* be knowingly changed in
888 any new, future 1.x release. If an interface change should ever
889 become necessary due to extraordinary circumstances, the change
890 and an appropriate transition strategy will be documented in these
893 As you use SCons, please heed the following:
895 - Please report any bugs or other problems that you find to our bug
896 tracker at our SourceForge project page:
898 http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
900 We have a reliable bug-fixing methodology already in place and
901 strive to respond to problems relatively quickly.
903 - Documentation is spottier than we'd like. You may need to dive
904 into the source code to figure out how to do something. Asking
905 questions on the scons-users mailing list is also welcome. We
906 will be addressing the documentation in upcoming releases, but
907 would be more than glad to have your assistance in correcting this
910 - The "SCons Design" documentation on the SCons web site is very
911 out of date, as we made significant changes to portions of the
912 interface as we figured out what worked and what didn't during the
913 extensive beta implementation. The "SCons Design" document should
914 be used only for historical purposes, or for just an extremely
915 general understanding of SCons' architectural goals.
917 - There may be performance issues. Improving SCons performance
918 is an ongoing priority. If you still find the performance
919 unacceptable, we would very much like to hear from you and learn
920 more about your configuration so we can optimize the right things.
922 - Error messages don't always exist where they'd be helpful.
923 Please let us know about any errors you ran into that would
924 have benefitted from a (more) descriptive message.
926 KNOWN PROBLEMS IN THIS RELEASE:
928 For a complete list of known problems, consult the SCons Issue Tracker
931 http://scons.tigris.org/project_issues.html
933 - Support for parallel builds (-j) does not work on WIN32 systems
934 prior to *official* Python release 2.2 (not 2.2 pre-releases).
936 Prior to Python 2.2, there is a bug in Python's Win32
937 implementation such that when a thread spawns an external command,
938 it blocks all threads from running. This breaks the SCons
939 multithreading architecture used to support -j builds.
941 We have included a patch file, os_spawnv_fix.diff, that you can
942 use if you you want to fix your version of Python to support
943 parallel builds in SCons.
945 - Again, the "SCons Design" documentation on the SCons web site is
946 out of date. Take what you read there with a grain of salt.
948 - On Win32 systems, you must put a space between the redirection
949 characters < and >, and the specified files (or construction
950 variable expansions):
952 command < $SOURCE > $TARGET
954 If you don't supply a space (for example, "<$SOURCE"), SCons will
955 not recognize the redirection.
957 - MSVC .res files are not rebuilt when icons change.
959 - The -c option does not clean up .sconsign files or directories
960 created as part of the build, and also does not clean up
961 SideEffect files (for example, Visual Studio .pdb files).
963 - When using multiple Repositories, changing the name of an include
964 file can cause an old version of the file to be used.
966 - There is currently no way to force use of a relative path (../*)
967 for directories outside the top-level SConstruct file.
969 - The Jar() Builder will, on its second or subsequent invocation,
970 package up the .sconsign files that SCons uses to track signatures.
971 You can work around this by using the SConsignFile() function
972 to collect all of the .sconsign information into a single file
973 outside of the directory being packaged by Jar().
975 - SCons does not currently have a way to detect that an intermediate
976 file has been corrupted from outside and should be rebuilt.
978 - Unicode characters in path names do not work in all circumstances.
980 - SCons does not currently automatically check out SConstruct or
981 SConscript files from SCCS, RCS or BitKeeper.
983 - No support yet for the following planned command-line options:
985 -d -e -l --list-actions --list-derived --list-where
986 -o --override -p -r -R -w --write-filenames
987 -W --warn-undefined-variables
991 Thank you for your interest, and please let us know how we can help
992 improve SCons for your needs.
995 knight at baldmt dot com
996 http://www.baldmt.com/~knight/
998 With plenty of help from the SCons Development team: