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
25 Please consult the CHANGES.txt file for a list of specific changes
28 Please note the following important changes since release 1.1.0:
30 -- THE $CHANGED_SOURCES, $CHANGED_TARGETS, $UNCHANGED_SOURCES
31 AND $UNCHANGED_TARGETS VARIABLES WILL BECOME RESERVED
33 A future release (probably 1.3.0) will make the construction
34 variable names $CHANGED_SOURCES, $CHANGED_TARGETS,
35 $UNCHANGED_SOURCES and $UNCHANGED_TARGETS into reserved
36 construction variable names controlled by SCons itself (like
37 the current $SOURCE, $TARGETS, etc.).
39 Setting these variable names in the current release will generate
40 a warning but still set the variables. When they become reserved
41 variable names, they will generate a different warning message
42 and attempts to set these variables will be ignored.
44 SCons configurations that happen to use these variable names
45 should be changed to use different variable names, in order
46 to ensure that the configuration continues to work with future
49 Please note the following important changes since release 0.98.4:
51 -- scons.bat NOW RETURNS THE REAL SCONS EXIT STATUS
53 The scons.bat script shipped with SCons used to exit with
54 a status of 1 when it detected any failed (non-zero) exit
55 status from the underlying Python execution of SCons itself.
56 The scons.bat script now exits with the actual status
59 -- SCONS NOW WARNS WHEN TRYING TO LINK C++ AND FORTRAN OBJECT FILES
61 Some C++ toolchains do not understand Fortran runtimes and create
62 unpredictable executables when linking C++ and Fortran object
63 files together. SCons now issues a warning if you try to link
64 C++ and Fortran object files into the same executable:
66 scons: warning: Using $CXX to link Fortran and C++ code together.
67 This may generate a buggy executable if the '/usr/bin/gcc'
68 compiler does not know how to deal with Fortran runtimes.
70 The warning may be suppressed with either the --warning=no-link
71 or --warning=no-fortran-cxx-mix command line options, or by
72 adding either of the following lines to a SConscript file:
74 SetOption('warn', 'no-link')
75 SetOption('warn', 'no-fortran-cxx-mix')
77 Please note the following important changes since release 0.98:
79 -- SCONS NO LONGER SETS THE GNU TOOLCHAIN -fPIC FLAG IN $SHCXXFLAGS
81 The GNU toolchain support in previous versions of SCons would
82 add the -fPIC flag to the $SHCXXFLAGS construction variable.
83 The -fPIC flag has been now been removed from the default
84 $SHCXXFLAGS setting. Instead, the $SHCXXCOM construction variable
85 (the default SCons command line for compiling shared objects
86 from C++ source files) has been changed to add the $SHCCFLAGS
87 variable, which contains the -fPIC flag.
89 This change was made in order to make the behavior of the default
90 C++ compilation line including $SHCCFLAGS consistent with the
91 default C compilation line including $CCFLAGS.
93 This change should have no impact on configurations that use
94 the default $SHCXXCOM command line. It may have an impact on
95 configurations that were using the default $SHCXXFLAGS value
96 *without* the $SHCCFLAGS variable to get the -fPIC flag into a
97 custom command line. You can fix these by adding the $SHCCFLAGS
98 to the custom command line.
100 Adding $SHCCFLAGS is backwards compatible with older SCons
101 releases, although it might cause the -fPIC flag to be repeated
102 on the command line if you execute it on an older version of
103 SCons that sets -fPIC in both the $SHCCLAFGS and $SHCXXFLAGS
104 variables. Duplicating the -fPIC flag on the g++ command line
105 will not cause any compilation problems, but the change to the
106 command line may cause SCons to rebuild object files.
108 -- FORTRAN NOW COMPILES .f FILES WITH gfortran BY DEFAULT
110 The Fortran Tool modules have had a major overhaul with the intent
111 of making them work as-is for most configurations. In general,
112 most configurations that use default settings should not see
113 any noticeable difference.
115 One configuration that has changed is if you have both a gfortran
116 and g77 compiler installed. In this case, previous versions of
117 SCons would, by default, use g77 by default to compile files with
118 a .f suffix, while SCons 0.98.1 will use the gfortran compiler
119 by default. The old behavior may be preserved by explicitly
120 initializing construction environments with the 'g77' Tool module:
122 env = Environment(tools = ['g77', 'default'])
124 The above code is backwards compatible to older versions of SCons.
126 If you notice any other changes in the behavior of default
127 Fortran support, please let us know so we can document them in
128 these release notes for other users.
130 Please note the following important changes since release 0.97.0d20071212:
132 -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.2 IS NOW DEPRECATED
134 SCons now prints the following warning when it is run by any
135 Python 1.5, 2.0 or 2.1 release or sub-release:
137 scons: warning: Support for pre-2.2 Python (VERSION) is deprecated.
138 If this will cause hardship, contact dev@scons.tigris.org.
140 You may disable all warnings about deprecated features by adding
141 the option "--warn=no-deprecated" to the command line or to the
142 $SCONSFLAGS environment variable:
144 $ scons --warn=no-deprecated
146 Using '--warn=no-deprecated' is compatible with earlier versions
149 You may also, as of this version of SCons, disable all warnings
150 about deprecated features by adding the following to any
153 SetOption('warn', 'no-deprecated')
155 You may disable only the specific warning about running under
156 a deprecated Python version by adding the following to any
159 SetOption('warn', 'no-python-version')
161 The warning may also be suppressed on the command line:
163 $ scons --warn=no-python-version
165 Or by specifying the --warn=no-python-version option in the
166 $SCONSFLAGS environment variable.
168 Using SetOption('warn', ...), and the 'no-python-version'
169 command-line option for suppressing this specific warning,
170 are *not* backwards-compatible to earlier versions of SCons.
172 -- THE env.Copy() METHOD IS NOW OFFICIALLY DEPRECATED
174 The env.Copy() method is now officially deprecated and will
175 be removed in a future release. Using the env.Copy() method
176 now generates the following message:
178 scons: warning: The env.Copy() method is deprecated; use the env.Clone() method instead.
180 You may disable all warnings about deprecated features by adding
181 the option "--warn=no-deprecated" to the command line or to the
182 $SCONSFLAGS environment variable:
184 $ scons --warn=no-deprecated
186 Using '--warn=no-deprecated' is compatible with earlier versions
189 You may also, as of this version of SCons, disable all warnings
190 about deprecated features by adding the following to any
193 SetOption('warn', 'no-deprecated')
195 You may disable only the specific warning about the deprecated
196 env.Copy() method by adding the following to any SConscript
199 SetOption('warn', 'no-deprecated-copy')
201 The warning may also be suppressed on the command line:
203 $ scons --warn=no-deprecated-copy
205 Or by specifying the --warn=no-deprecated-copy option in the
206 $SCONSFLAGS environment variable.
208 Using SetOption('warn', ...), and the 'no-deprecated-copy'
209 command-line option for suppressing this specific warning,
210 are *not* backwards-compatible to earlier versions of SCons.
212 -- THE --debug=dtree, --debug=stree AND --debug=tree OPTIONS ARE DEPRECATED
214 The --debug=dtree, --debug=stree and --debug=tree methods
215 are now officially deprecated and will be removed in a
216 future release. Using these options now generate a warning
217 message recommending use of the --tree=derived, --tree=all,status
218 and --tree=all options, respectively.
220 You may disable these warnings, and all warnings about
221 deprecated features, by adding the option "--warn=no-deprecated"
222 to the command line or to the $SCONSFLAGS environment
225 $ scons --warn=no-deprecated
227 Using '--warn=no-deprecated' is compatible with earlier versions
230 -- THE TargetSignatures() AND SourceSignatures() FUNCTIONS ARE DEPRECATED
232 The TargetSignatures() and SourceSignatures() functions,
233 and their corresponding env.TargetSignatures() and
234 env.SourceSignatures() methods, are now officially deprecated
235 and will be be removed in a future release. Using ahy of
236 these functions or methods now generates a message
237 similar to the following:
239 scons: warning: The env.TargetSignatures() method is deprecated;
240 convert your build to use the env.Decider() method instead.
242 You may disable all warnings about deprecated features by adding
243 the option "--warn=no-deprecated" to the command line or to the
244 $SCONSFLAGS environment variable:
246 $ scons --warn=no-deprecated
248 Using '--warn=no-deprecated' is compatible with earlier versions
251 You may also, as of this version of SCons, disable all warnings
252 about deprecated features by adding the following to any
255 SetOption('warn', 'no-deprecated')
257 You may disable only the specific warning about the use of
258 TargetSignatures() or SourceSignatures() by adding the
259 following to any SConscript file:
261 SetOption('warn', 'no-deprecated-target-signatures')
262 SetOption('warn', 'no-deprecated-source-signatures')
264 The warnings may also be suppressed on the command line:
266 $ scons --warn=no-deprecated-target-signatures --warn=no-deprecated-source-signatures
268 Or by specifying these options in the $SCONSFLAGS environment
271 Using SetOption('warn', ...), or the command-line options
272 for suppressing these warnings, is *not* backwards-compatible
273 to earlier versions of SCons.
275 -- File(), Dir() and Entry() NOW RETURN A LIST WHEN THE INPUT IS A SEQUENCE
277 Previously, if these methods were passed a list, the list was
278 substituted and stringified, then passed as a single string to
279 create a File/Dir/Entry Node. This rarely if ever worked with
280 more than one element in the list. They now return a list of
281 Nodes when passed a list.
283 One case that works differently now is a passing in a
284 single-element sequence; that formerly was stringified
285 (returning its only element) and then a single Node would be
286 returned. Now a single-element list containing the Node will
287 be returned, for consistency.
289 -- THE env.subst() METHOD NOW RETURNS A LIST WHEN THE INPUT IS A SEQUENCE
291 The env.subst() method now returns a list with the elements
292 expanded when given a list as input. Previously, the env.subst()
293 method would always turn its result into a string.
295 This behavior was changed because it interfered with being able
296 to include things like lists within the expansion of variables
297 like $CPPPATH and then have SCons understand that the elements
298 of the "internal" lists still needed to be treated separately.
299 This would cause a $CPPPATH list like ['subdir1', 'subdir']
300 to show up in a command line as "-Isubdir1 subdir".
302 -- THE Jar() BUILDER NOW USES THE Java() BUILDER CLASSDIR BY DEFAULT
304 By default, the Jar() Builder will now use the class directory
305 specified when the Java() builder is called. So the following
308 classes = env.Java('classes', 'src')
309 env.Jar('out.jar', classes)
311 Will cause "-C classes" to be passed the "jar" command invocation,
312 and the Java classes in the "out.jar" file will not be prefixed
315 Explicitly setting the $JARCHDIR variable overrides this default
316 behavior. The old behavior of not passing any -C option to the
317 "jar" command can be preserved by explicitly setting $JARCHDIR
320 env = Environment(JARCHDIR = None)
322 The above setting is compatible with older versions of SCons.
324 Please note the following important changes since release 0.97.0d20070918:
326 -- SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS
327 ON OPEN FILE HANDLES TO CREATED PROCESSES
329 On Windows systems, SCons now redefines the Python open()
330 and file() functions so that, if the Python Win32 extensions
331 are available, the file handles for any opened files will *not*
332 be inherited by subprocesses, such as the spawned compilers and
333 other tools invoked to build the software.
335 This prevents certain race conditions where a file handle for
336 a file opened by Python (either in a Python function action,
337 or directly in a SConscript file) could be inherited and help
338 open by a subprocess, interfering with the ability of other
339 processes to create or modify the file.
341 In general, this should not cause problems for the vast majority
342 of configurations. The only time this would be a problem would be
343 in the unlikely event that a process spawned by SCons specifically
344 *expected* to use an inherited file handle opened by SCons.
346 If the Python Win32 extensions are not installed or are an
347 earlier version that does not have the ability to disable file
348 handle inheritance, SCons will print a warning message when the
349 -j option is used. The warning message may be suppressed by
350 specifying --warn=no-parallel-support.
352 Please note the following important changes since release 0.97.0d20070809:
354 -- "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR
356 The default behavior of SCons is now to use the MD5 checksum of
357 all file contents to decide if any files have changed and should
358 cause rebuilds of their source files. This means that SCons may
359 decide not to rebuild "downstream" targets if a a given input
360 file is rebuilt to the exact same contents as the last time.
361 The old behavior may preserved by explicity specifying:
363 TargetSignatures("build")
365 In any of your SConscript files.
367 -- TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM
369 For all targets built by calling external commands (such as a
370 compiler or other utility), SCons now adds an implicit dependency
371 on the command(s) used to build the target.
373 This will cause rebuilds of all targets built by external commands
374 when running SCons in a tree built by previous version of SCons,
375 in order to update the recorded signatures.
377 The old behavior of not having targets depend on the external
378 commands that build them can be preserved by setting a new
379 $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a
382 env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0)
384 or by adding Ignore() calls for any targets where the behavior
387 Ignore('/usr/bin/gcc', 'foo.o')
389 Both of these settings are compatible with older versions
392 -- CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS
394 If you change the SourceSignature() value from 'timestamp' to
395 'MD5', SCons will now rebuild targets that were already up-to-date
396 with respect to their source files.
398 This will happen because SCons did not record the content
399 signatures of the input source files when the target was last
400 built--it only recorded the timestamps--and it must record them
401 to make sure the signature information is correct. However,
402 the content of source files may have changed since the last
403 timestamp build was performed, and SCons would not have any way to
404 verify that. (It would have had to open up the file and record
405 a content signature, which is one of the things you're trying to
406 avoid by specifying use of timestamps....) So in order to make
407 sure the built targets reflect the contents of the source files,
408 the targets must be rebuilt.
410 Change the SourceSignature() value from 'MD5' to 'timestamp'
411 should correctly not rebuild target files, because the timestamp
412 of the files is always recorded.
414 In previous versions of SCons, changing the SourceSignature()
415 value would lead to unpredictable behavior, usually including
418 -- THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY
420 The Return() function now immediately stops processing the
421 SConscript file in which it appears and returns the values of the
422 variables named in its arguments. It used to continue processing
423 the rest of the SConscript file, and then return the values of the
424 specified variables at the point the Return() function was called.
426 The old behavior may be requested by adding a "stop=False"
427 keyword argument to the Return() call:
429 Return('value', stop=False)
431 The "stop=" keyword argument is *not* compatible with SCons
432 versions 0.97.0d20070809 or earlier.
434 Please note the following important changes since release 0.97:
436 -- env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS
438 The env.CacheDir() method now only causes derived files to be
439 retrieved from the specified cache directory for targets built
440 with the specified specified construction environment ("env").
442 Previously, any call to env.CacheDir() or CacheDir() would modify
443 a global setting and cause all built targets to be retrieved
444 from the specified cache directory. This behavior was changed so
445 that env.CacheDir() would be consistent with other construction
446 environment methods, which only affect targets built with the
447 specified construction environment.
449 The old behavior of changing the global behavior may be preserved
450 by changing any env.CacheDir() calls to:
452 CacheDir('/path/to/cache/directory')
454 The above change is backwards-compatible and works in all earlier
455 versions of SCons that support CacheDir().
457 -- INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED
459 The interpretation of source arguments (files) without suffixes
460 has changed in one specific configuration.
462 Previously, if a Builder had a src_suffix specified (indicating
463 that source files without suffixes should have that suffix
464 appended), the suffix would only be applied to suffix-less source
465 arguments if the Builder did *not* have one or more attached
466 source Builders (that is, the Builder was not a "multi-stage"
467 Builder). So in the following configuration:
469 build_foo = Builder(src_suffix = '.foo')
470 build_bar = Builder(src_suffix = '.bar',
471 src_builder = build_bar)
473 env = Environment(BUILDERS = {
478 env.Foo('tgt1', 'src1')
479 env.Bar('tgt2', 'src2')
481 SCons would have expected to find a source file 'src1.foo' for the
482 env.Foo() call, but a source file 'src2' for the env.Bar() call.
484 This behavior has now been made consistent, so that the two
485 above calls would expect source files named 'src1.foo' and
486 'src2.bar', respectively.
488 Note that, if genuinely desired, the old behavior of building
489 from a source file without a suffix at all (when the Builder has
490 a src_suffix *and* a src_builder) can be specified explicity by
491 turning the string into a File Node directly:
493 env.Bar('tgt2', File('src2'))
495 The above use of File() is backwards-compatible and will work
496 on earlier versions of SCons.
498 -- THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED
500 On Solaris systems, SCons now adds the "/opt/SUNWspro/bin"
501 directory to the default execution $PATH variable before the
502 "/usr/ccs/bin" directory. This was done to reflect the fact
503 that /opt/SUNWspro/ is the default for SUN tools, but it may
504 cause a different compiler to be used if you have compilers
505 installed in both directories.
507 -- GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1"
509 When generating a "config.h" file, SCons now defines values that
510 record the existence of a feature with a "1" value:
512 #define HAVE_FEATURE 1
514 Instead of printing the line without a "1", as it used to:
518 This should not cause any problems in the normal use of "#ifdef
519 HAVE_{FEATURE}" statements interpreted by a C preprocessor, but
520 might cause a compatibility issue if a script or other utility
521 looks for an exact match of the previous text.
523 Please note the following planned, future changes:
525 -- THE Options OBJECT AND RELATED FUNCTIONS WILL BE DEPRECATED
527 The Options object is being replaced by a new Variables
528 object, which uses a new Variables.AddVariable() method
529 where the previous interface used Options.AddOptions().
531 Similarly, the following utility functions are being replaced
532 by the following similarly-named functions:
534 BoolOption() BoolVariable()
535 EnumOption() EnumVariable()
536 ListOption() ListVariable()
537 PackageOption() PackageVariable()
538 PathOption() PathVariable()
540 And also related, the options= keyword argument when creating
541 construction environments with the Environment() functions is
542 being replaced with a variables= keyword argument.
544 In some future release a deprecation warning will be added to
545 existing uses of the Options object, its methods, the above
546 utility functions, and the options= keyword argument of the
547 Environment() function. At some point after the deprecation
548 warning is added, the Options object, related functions and
549 options= keyword argument will be removed entirely.
551 You can prepare for this by changing all your uses of the Options
552 object and related functions to the Variables object and the new
553 function names, and changing any uses of the options= keyword
554 argument to variables=.
556 NOTE: CONVERTING TO USING THE NEW Variables OBJECT OR THE
557 RELATED *Variable() FUNCTIONS, OR USING THE NEW variable=
558 KEYWORD ARGUMENT, IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF
559 SCons BEFORE 0.98. YOUR SConscript FILES WILL NOT WORK ON
560 EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE.
562 If you change SConscript files in software that you make available
563 for download or otherwise distribute, other users may try to
564 build your software with an earlier version of SCons that does
565 not have the Variables object or related *Variable() functions.
566 We recommend preparing for this in one of two ways:
568 -- Make your SConscript files backwards-compatible by
569 modifying your calls with Python try:-except: blocks
573 vars = Variables('custom.py', ARGUMENTS)
575 BoolVariable('WARNINGS', 'cmopile with -Wall', 1),
576 EnumVariable('DEBUG', 'debug version', 'no'
577 allowed_values=('yes', 'no', 'full'),
578 map={}, ignorecase=0),
579 ListVariable('SHAREDLIBS',
580 'libraries to build shared',
582 names = list_of_libs),
583 PackageVariable('X11',
586 PathVariable('QTDIR', 'root of Qt', qtdir),
589 vars = Options('custom.py', ARGUMENTS)
591 BoolOption('WARNINGS', 'cmopile with -Wall', 1),
592 EnumOption('DEBUG', 'debug version', 'no'
593 allowed_values=('yes', 'no', 'full'),
594 map={}, ignorecase=0),
595 ListOption('SHAREDLIBS',
596 'libraries to build shared',
598 names = list_of_libs),
602 PathOption('QTDIR', 'root of Qt', qtdir),
605 Additionally, you can check for availability of the new
606 variables= keyword argument as follows:
609 env = Environment(variables=vars)
611 env = Environment(options=vars)
613 (Note that we plan to maintain the existing Options object
614 name for some time, to ensure backwards compatibility,
615 so in practice it may be easier to just continue to use
616 the old name until you're reasonably sure you won't have
617 people trying to build your software with versions of
618 SCons earlier than 0.98.1.)
620 -- Use the EnsureSConsVersion() function to provide a
621 descriptive error message if your SConscript files
622 are executed by an earlier version of SCons:
624 EnsureSConsVersion(0, 98, 1)
626 -- THE BuildDir() METHOD AND FUNCTION WILL BE DEPRECATED
628 The env.BuildDir() method and BuildDir() function are being
629 replaced by the new env.VariantDir() method and VariantDir()
632 In some future release a deprecation warning will be added
633 to existing uses of the env.BuildDir() method and BuildDir()
634 function. At some point after the deprecation warning, the
635 env.Builder() method and BuildDir() function will either
636 be removed entirely or have their behavior changed.
638 You can prepare for this by changing all your uses of the
639 env.BuildDir() method to env.VariantDir() and uses of the
640 global BuildDir() function to VariantDir(). If you use a
641 named keyword argument of "build_dir" when calling
642 env.BuildDir() or BuildDir():
644 env.BuildDir(build_dir='opt', src_dir='src')
646 The keyword must be changed to "variant_dir":
648 env.VariantDir(variant_dir='opt', src_dir='src')
650 NOTE: CHANGING USES OF env.BuildDir() AND BuildDir() to
651 env.VariantDir() AND VariantDir() IS NOT BACKWARDS COMPATIBLE
652 TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES
653 WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING
656 If you change SConscript files in software that you make
657 available for download or otherwise distribute, other users
658 may try to build your software with an earlier version of
659 SCons that does not have the env.VariantDir() method or
660 VariantDir() fnction. We recommend preparing for this in
663 -- Make your SConscript files backwards-compatible by
664 including the following code near the beginning of your
665 top-level SConstruct file:
667 import SCons.Environment
669 SCons.Environment.Environment.VariantDir
670 except AttributeError:
671 SCons.Environment.Environment.VariantDir = \
672 SCons.Environment.Environment.BuildDir
674 -- Use the EnsureSConsVersion() function to provide a
675 descriptive error message if your SConscript files
676 are executed by an earlier version of SCons:
678 EnsureSConsVersion(0, 98)
680 -- THE SConscript() "build_dir" KEYWORD ARGUMENT WILL BE DEPRECATED
682 The "build_dir" keyword argument of the SConscript function
683 and env.SConscript() method are being replaced by a new
684 "variant_dir" keyword argument.
686 In some future release a deprecation warning will be added
687 to existing uses of the SConscript()/env.SConscript()
688 "build_dir" keyword argument. At some point after the
689 deprecation warning, support for this keyword argument will
692 You can prepare for this by changing all your uses of the
693 SConscript()/env.SConscript() 'build_dir" keyword argument:
695 SConscript('src/SConscript', build_dir='opt')
697 To use the new "variant_dir" keyword argument:
699 SConscript('src/SConscript', variant_dir='opt')
701 NOTE: USING THE NEW "variant_dir" KEYWORD IS NOT BACKWARDS
702 COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript
703 FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER
706 If you change SConscript files in software that you make
707 available for download or otherwise distribute, other users
708 may try to build your software with an earlier version of
709 SCons that does not support the "variant_dir" keyword.
711 If you can insist that users use a recent version of SCons
712 that supports "variant_dir", we recommend using the
713 EnsureSConsVersion() function to provide a descriptive error
714 message if your SConscript files are executed by an earlier
717 EnsureSConsVersion(0, 98)
719 If you want to make sure that your SConscript files will
720 still work with earlier versions of SCons, then your best
721 bet is to continue to use the "build_dir" keyword until the
722 support is removed (which, in all likelihood, won't happen
723 for quite some time).
725 -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
727 Several internal variable names in SCons.Defaults for various
728 pre-made default Scanner objects have been deprecated and will
729 be removed in a future revision. In their place are several new
730 global variable names that are now part of the publicly-supported
733 NEW NAME DEPRECATED NAME
734 -------- ----------------------------
735 CScanner SCons.Defaults.CScan
736 DSCanner SCons.Defaults.DScan
737 SourceFileScanner SCons.Defaults.ObjSourceScan
738 ProgramScanner SCons.Defaults.ProgScan
740 Of these, only ObjSourceScan was probably used at all, to add
741 new mappings of file suffixes to other scanners for use by the
742 Object() Builder. This should now be done as follows:
744 SourceFileScanner.add_scanner('.x', XScanner)
746 -- THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY
748 The env.Copy() method (to make a copy of a construction
749 environment) is being replaced by the env.Clone() method.
751 As of SCons 0.98, a deprecation warning has been added to
752 current uses of the env.Copy() method. At some point in
753 the future, the env.Copy() method will either be removed
754 entirely or have its behavior changed.
756 You can prepare for this by changing all your uses of env.Copy()
757 to env.Clone(), which has the exact same calling arguments.
759 NOTE: CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE
760 YOUR SConscript FILES NOT WORK ON VERSIONS OF SCons BEFORE
763 If you change SConscript files in software that you make
764 available for download or otherwise distribute, other users
765 may try to build your software with an earlier version of
766 SCons that does not have the env.Clone() method. We recommend
767 preparing for this in one of two ways:
769 -- Make your SConscript files backwards-compatible by
770 including the following code near the beginning of your
771 top-level SConstruct file:
773 import SCons.Environment
775 SCons.Environment.Environment.Clone
776 except AttributeError:
777 SCons.Environment.Environment.Clone = \
778 SCons.Environment.Environment.Copy
780 -- Use the EnsureSConsVersion() function to provide a
781 descriptive error message if your SConscript files
782 are executed by an earlier version of SCons:
784 EnsureSConsVersion(0, 96, 93)
786 SCons is developed with an extensive regression test suite, and a
787 rigorous development methodology for continually improving that suite.
788 Because of this, SCons is of sufficient quality that you can use it
791 The interfaces in release 1.0 will *not* be knowingly changed in
792 any new, future 1.x release. If an interface change should ever
793 become necessary due to extraordinary circumstances, the change
794 and an appropriate transition strategy will be documented in these
797 As you use SCons, please heed the following:
799 - Please report any bugs or other problems that you find to our bug
800 tracker at our SourceForge project page:
802 http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
804 We have a reliable bug-fixing methodology already in place and
805 strive to respond to problems relatively quickly.
807 - Documentation is spottier than we'd like. You may need to dive
808 into the source code to figure out how to do something. Asking
809 questions on the scons-users mailing list is also welcome. We
810 will be addressing the documentation in upcoming releases, but
811 would be more than glad to have your assistance in correcting this
814 - The "SCons Design" documentation on the SCons web site is very
815 out of date, as we made significant changes to portions of the
816 interface as we figured out what worked and what didn't during the
817 extensive beta implementation. The "SCons Design" document should
818 be used only for historical purposes, or for just an extremely
819 general understanding of SCons' architectural goals.
821 - There may be performance issues. Improving SCons performance
822 is an ongoing priority. If you still find the performance
823 unacceptable, we would very much like to hear from you and learn
824 more about your configuration so we can optimize the right things.
826 - Error messages don't always exist where they'd be helpful.
827 Please let us know about any errors you ran into that would
828 have benefitted from a (more) descriptive message.
830 KNOWN PROBLEMS IN THIS RELEASE:
832 For a complete list of known problems, consult the SCons Issue Tracker
835 http://scons.tigris.org/project_issues.html
837 - Support for parallel builds (-j) does not work on WIN32 systems
838 prior to *official* Python release 2.2 (not 2.2 pre-releases).
840 Prior to Python 2.2, there is a bug in Python's Win32
841 implementation such that when a thread spawns an external command,
842 it blocks all threads from running. This breaks the SCons
843 multithreading architecture used to support -j builds.
845 We have included a patch file, os_spawnv_fix.diff, that you can
846 use if you you want to fix your version of Python to support
847 parallel builds in SCons.
849 - Again, the "SCons Design" documentation on the SCons web site is
850 out of date. Take what you read there with a grain of salt.
852 - On Win32 systems, you must put a space between the redirection
853 characters < and >, and the specified files (or construction
854 variable expansions):
856 command < $SOURCE > $TARGET
858 If you don't supply a space (for example, "<$SOURCE"), SCons will
859 not recognize the redirection.
861 - MSVC .res files are not rebuilt when icons change.
863 - The -c option does not clean up .sconsign files or directories
864 created as part of the build, and also does not clean up
865 SideEffect files (for example, Visual Studio .pdb files).
867 - When using multiple Repositories, changing the name of an include
868 file can cause an old version of the file to be used.
870 - There is currently no way to force use of a relative path (../*)
871 for directories outside the top-level SConstruct file.
873 - The Jar() Builder will, on its second or subsequent invocation,
874 package up the .sconsign files that SCons uses to track signatures.
875 You can work around this by using the SConsignFile() function
876 to collect all of the .sconsign information into a single file
877 outside of the directory being packaged by Jar().
879 - SCons does not currently have a way to detect that an intermediate
880 file has been corrupted from outside and should be rebuilt.
882 - Unicode characters in path names do not work in all circumstances.
884 - SCons does not currently automatically check out SConstruct or
885 SConscript files from SCCS, RCS or BitKeeper.
887 - No support yet for the following planned command-line options:
889 -d -e -l --list-actions --list-derived --list-where
890 -o --override -p -r -R -w --write-filenames
891 -W --warn-undefined-variables
895 Thank you for your interest, and please let us know how we can help
896 improve SCons for your needs.
899 knight at baldmt dot com
900 http://www.baldmt.com/~knight/
902 With plenty of help from the SCons Development team: