2 # __FILE__ __REVISION__ __DATE__ __DEVELOPER__
5 SCons - a software construction tool
10 This is a beta release of SCons, a tool for building software (and other
11 files). SCons is implemented in Python, and its "configuration files"
12 are actually Python scripts, allowing you to use the full power of a
13 real scripting language to solve build problems. You do not, however,
14 need to know Python to 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 This is an update to the ninth beta release of SCons. Please consult
26 the CHANGES.txt file for a list of specific changes since last release.
28 Please note the following important changes since release 0.98:
30 -- SCONS NO LONGER SETS THE GNU TOOLCHAIN -fPIC FLAG IN $SHCXXFLAGS
32 The GNU toolchain support in previous versions of SCons would
33 add the -fPIC flag to the $SHCXXFLAGS construction variable.
34 The -fPIC flag has been now been removed from the default
35 $SHCXXFLAGS setting. Instead, the $SHCXXCOM construction variable
36 (the default SCons command line for compiling shared objects
37 from C++ source files) has been changed to add the $SHCCFLAGS
38 variable, which contains the -fPIC flag.
40 This change was made in order to make the behavior of the default
41 C++ compilation line including $SHCCFLAGS consistent with the
42 default C compilation line including $CCFLAGS.
44 This change should have no impact on configurations that use
45 the default $SHCXXCOM command line. It may have an impact on
46 configurations that were using the default $SHCXXFLAGS value
47 *without* the $SHCCFLAGS variable to get the -fPIC flag into a
48 custom command line. You can fix these by adding the $SHCCFLAGS
49 to the custom command line.
51 Adding $SHCCFLAGS is backwards compatible with older SCons
52 releases, although it might cause the -fPIC flag to be repeated
53 on the command line if you execute it on an older version of
54 SCons that sets -fPIC in both the $SHCCLAFGS and $SHCXXFLAGS
55 variables. Duplicating the -fPIC flag on the g++ command line
56 will not cause any compilation problems, but the change to the
57 command line may cause SCons to rebuild object files.
59 Please note the following important changes since release 0.97.0d20071212:
61 -- SUPPORT FOR PYTHON VERSIONS BEFORE 2.2 IS NOW DEPRECATED
63 SCons now prints the following warning when it is run by any
64 Python 1.5, 2.0 or 2.1 release or sub-release:
66 scons: warning: Support for pre-2.2 Python (VERSION) is deprecated.
67 If this will cause hardship, contact dev@scons.tigris.org.
69 You may disable all warnings about deprecated features by adding
70 the option "--warn=no-deprecated" to the command line or to the
71 $SCONSFLAGS environment variable:
73 $ scons --warn=no-deprecated
75 Using '--warn=no-deprecated' is compatible with earlier versions
78 You may also, as of this version of SCons, disable all warnings
79 about deprecated features by adding the following to any
82 SetOption('warn', 'no-deprecated')
84 You may disable only the specific warning about running under
85 a deprecated Python version by adding the following to any
88 SetOption('warn', 'no-python-version')
90 The warning may also be suppressed on the command line:
92 $ scons --warn=no-python-version
94 Or by specifying the --warn=no-python-version option in the
95 $SCONSFLAGS environment variable.
97 Using SetOption('warn', ...), and the 'no-python-version'
98 command-line option for suppressing this specific warning,
99 are *not* backwards-compatible to earlier versions of SCons.
101 -- THE env.Copy() METHOD IS NOW OFFICIALLY DEPRECATED
103 The env.Copy() method is now officially deprecated and will
104 be removed in a future release. Using the env.Copy() method
105 now generates the following message:
107 scons: warning: The env.Copy() method is deprecated; use the env.Clone() method instead.
109 You may disable all warnings about deprecated features by adding
110 the option "--warn=no-deprecated" to the command line or to the
111 $SCONSFLAGS environment variable:
113 $ scons --warn=no-deprecated
115 Using '--warn=no-deprecated' is compatible with earlier versions
118 You may also, as of this version of SCons, disable all warnings
119 about deprecated features by adding the following to any
122 SetOption('warn', 'no-deprecated')
124 You may disable only the specific warning about the deprecated
125 env.Copy() method by adding the following to any SConscript
128 SetOption('warn', 'no-deprecated-copy')
130 The warning may also be suppressed on the command line:
132 $ scons --warn=no-deprecated-copy
134 Or by specifying the --warn=no-deprecated-copy option in the
135 $SCONSFLAGS environment variable.
137 Using SetOption('warn', ...), and the 'no-deprecated-copy'
138 command-line option for suppressing this specific warning,
139 are *not* backwards-compatible to earlier versions of SCons.
141 -- THE --debug=dtree, --debug=stree AND --debug=tree OPTIONS ARE DEPRECATED
143 The --debug=dtree, --debug=stree and --debug=tree methods
144 are now officially deprecated and will be removed in a
145 future release. Using these options now generate a warning
146 message recommending use of the --tree=derived, --tree=all,status
147 and --tree=all options, respectively.
149 You may disable these warnings, and all warnings about
150 deprecated features, by adding the option "--warn=no-deprecated"
151 to the command line or to the $SCONSFLAGS environment
154 $ scons --warn=no-deprecated
156 Using '--warn=no-deprecated' is compatible with earlier versions
159 -- THE TargetSignatures() AND SourceSignatures() FUNCTIONS ARE DEPRECATED
161 The TargetSignatures() and SourceSignatures() functions,
162 and their corresponding env.TargetSignatures() and
163 env.SourceSignatures() methods, are now officially deprecated
164 and will be be removed in a future release. Using ahy of
165 these functions or methods now generates a message
166 similar to the following:
168 scons: warning: The env.TargetSignatures() method is deprecated;
169 convert your build to use the env.Decider() method instead.
171 You may disable all warnings about deprecated features by adding
172 the option "--warn=no-deprecated" to the command line or to the
173 $SCONSFLAGS environment variable:
175 $ scons --warn=no-deprecated
177 Using '--warn=no-deprecated' is compatible with earlier versions
180 You may also, as of this version of SCons, disable all warnings
181 about deprecated features by adding the following to any
184 SetOption('warn', 'no-deprecated')
186 You may disable only the specific warning about the use of
187 TargetSignatures() or SourceSignatures() by adding the
188 following to any SConscript file:
190 SetOption('warn', 'no-deprecated-target-signatures')
191 SetOption('warn', 'no-deprecated-source-signatures')
193 The warnings may also be suppressed on the command line:
195 $ scons --warn=no-deprecated-target-signatures --warn=no-deprecated-source-signatures
197 Or by specifying these options in the $SCONSFLAGS environment
200 Using SetOption('warn', ...), or the command-line options
201 for suppressing these warnings, is *not* backwards-compatible
202 to earlier versions of SCons.
204 -- File(), Dir() and Entry() NOW RETURN A LIST WHEN THE INPUT IS A SEQUENCE
206 Previously, if these methods were passed a list, the list was
207 substituted and stringified, then passed as a single string to
208 create a File/Dir/Entry Node. This rarely if ever worked with
209 more than one element in the list. They now return a list of
210 Nodes when passed a list.
212 One case that works differently now is a passing in a
213 single-element sequence; that formerly was stringified
214 (returning its only element) and then a single Node would be
215 returned. Now a single-element list containing the Node will
216 be returned, for consistency.
218 -- THE env.subst() METHOD NOW RETURNS A LIST WHEN THE INPUT IS A SEQUENCE
220 The env.subst() method now returns a list with the elements
221 expanded when given a list as input. Previously, the env.subst()
222 method would always turn its result into a string.
224 This behavior was changed because it interfered with being able
225 to include things like lists within the expansion of variables
226 like $CPPPATH and then have SCons understand that the elements
227 of the "internal" lists still needed to be treated separately.
228 This would cause a $CPPPATH list like ['subdir1', 'subdir']
229 to show up in a command line as "-Isubdir1 subdir".
231 -- THE Jar() BUILDER NOW USES THE Java() BUILDER CLASSDIR BY DEFAULT
233 By default, the Jar() Builder will now use the class directory
234 specified when the Java() builder is called. So the following
237 classes = env.Java('classes', 'src')
238 env.Jar('out.jar', classes)
240 Will cause "-C classes" to be passed the "jar" command invocation,
241 and the Java classes in the "out.jar" file will not be prefixed
244 Explicitly setting the $JARCHDIR variable overrides this default
245 behavior. The old behavior of not passing any -C option to the
246 "jar" command can be preserved by explicitly setting $JARCHDIR
249 env = Environment(JARCHDIR = None)
251 The above setting is compatible with older versions of SCons.
253 Please note the following important changes since release 0.97.0d20070918:
255 -- SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS
256 ON OPEN FILE HANDLES TO CREATED PROCESSES
258 On Windows systems, SCons now redefines the Python open()
259 and file() functions so that, if the Python Win32 extensions
260 are available, the file handles for any opened files will *not*
261 be inherited by subprocesses, such as the spawned compilers and
262 other tools invoked to build the software.
264 This prevents certain race conditions where a file handle for
265 a file opened by Python (either in a Python function action,
266 or directly in a SConscript file) could be inherited and help
267 open by a subprocess, interfering with the ability of other
268 processes to create or modify the file.
270 In general, this should not cause problems for the vast majority
271 of configurations. The only time this would be a problem would be
272 in the unlikely event that a process spawned by SCons specifically
273 *expected* to use an inherited file handle opened by SCons.
275 If the Python Win32 extensions are not installed or are an
276 earlier version that does not have the ability to disable file
277 handle inheritance, SCons will print a warning message when the
278 -j option is used. The warning message may be suppressed by
279 specifying --warn=no-parallel-support.
281 Please note the following important changes since release 0.97.0d20070809:
283 -- "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR
285 The default behavior of SCons is now to use the MD5 checksum of
286 all file contents to decide if any files have changed and should
287 cause rebuilds of their source files. This means that SCons may
288 decide not to rebuild "downstream" targets if a a given input
289 file is rebuilt to the exact same contents as the last time.
290 The old behavior may preserved by explicity specifying:
292 TargetSignatures("build")
294 In any of your SConscript files.
296 -- TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM
298 For all targets built by calling external commands (such as a
299 compiler or other utility), SCons now adds an implicit dependency
300 on the command(s) used to build the target.
302 This will cause rebuilds of all targets built by external commands
303 when running SCons in a tree built by previous version of SCons,
304 in order to update the recorded signatures.
306 The old behavior of not having targets depend on the external
307 commands that build them can be preserved by setting a new
308 $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a
311 env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0)
313 or by adding Ignore() calls for any targets where the behavior
316 Ignore('/usr/bin/gcc', 'foo.o')
318 Both of these settings are compatible with older versions
321 -- CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS
323 If you change the SourceSignature() value from 'timestamp' to
324 'MD5', SCons will now rebuild targets that were already up-to-date
325 with respect to their source files.
327 This will happen because SCons did not record the content
328 signatures of the input source files when the target was last
329 built--it only recorded the timestamps--and it must record them
330 to make sure the signature information is correct. However,
331 the content of source files may have changed since the last
332 timestamp build was performed, and SCons would not have any way to
333 verify that. (It would have had to open up the file and record
334 a content signature, which is one of the things you're trying to
335 avoid by specifying use of timestamps....) So in order to make
336 sure the built targets reflect the contents of the source files,
337 the targets must be rebuilt.
339 Change the SourceSignature() value from 'MD5' to 'timestamp'
340 should correctly not rebuild target files, because the timestamp
341 of the files is always recorded.
343 In previous versions of SCons, changing the SourceSignature()
344 value would lead to unpredictable behavior, usually including
347 -- THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY
349 The Return() function now immediately stops processing the
350 SConscript file in which it appears and returns the values of the
351 variables named in its arguments. It used to continue processing
352 the rest of the SConscript file, and then return the values of the
353 specified variables at the point the Return() function was called.
355 The old behavior may be requested by adding a "stop=False"
356 keyword argument to the Return() call:
358 Return('value', stop=False)
360 The "stop=" keyword argument is *not* compatible with SCons
361 versions 0.97.0d20070809 or earlier.
363 Please note the following important changes since release 0.97:
365 -- env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS
367 The env.CacheDir() method now only causes derived files to be
368 retrieved from the specified cache directory for targets built
369 with the specified specified construction environment ("env").
371 Previously, any call to env.CacheDir() or CacheDir() would modify
372 a global setting and cause all built targets to be retrieved
373 from the specified cache directory. This behavior was changed so
374 that env.CacheDir() would be consistent with other construction
375 environment methods, which only affect targets built with the
376 specified construction environment.
378 The old behavior of changing the global behavior may be preserved
379 by changing any env.CacheDir() calls to:
381 CacheDir('/path/to/cache/directory')
383 The above change is backwards-compatible and works in all earlier
384 versions of SCons that support CacheDir().
386 -- INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED
388 The interpretation of source arguments (files) without suffixes
389 has changed in one specific configuration.
391 Previously, if a Builder had a src_suffix specified (indicating
392 that source files without suffixes should have that suffix
393 appended), the suffix would only be applied to suffix-less source
394 arguments if the Builder did *not* have one or more attached
395 source Builders (that is, the Builder was not a "multi-stage"
396 Builder). So in the following configuration:
398 build_foo = Builder(src_suffix = '.foo')
399 build_bar = Builder(src_suffix = '.bar',
400 src_builder = build_bar)
402 env = Environment(BUILDERS = {
407 env.Foo('tgt1', 'src1')
408 env.Bar('tgt2', 'src2')
410 SCons would have expected to find a source file 'src1.foo' for the
411 env.Foo() call, but a source file 'src2' for the env.Bar() call.
413 This behavior has now been made consistent, so that the two
414 above calls would expect source files named 'src1.foo' and
415 'src2.bar', respectively.
417 Note that, if genuinely desired, the old behavior of building
418 from a source file without a suffix at all (when the Builder has
419 a src_suffix *and* a src_builder) can be specified explicity by
420 turning the string into a File Node directly:
422 env.Bar('tgt2', File('src2'))
424 The above use of File() is backwards-compatible and will work
425 on earlier versions of SCons.
427 -- THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED
429 On Solaris systems, SCons now adds the "/opt/SUNWspro/bin"
430 directory to the default execution $PATH variable before the
431 "/usr/ccs/bin" directory. This was done to reflect the fact
432 that /opt/SUNWspro/ is the default for SUN tools, but it may
433 cause a different compiler to be used if you have compilers
434 installed in both directories.
436 -- GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1"
438 When generating a "config.h" file, SCons now defines values that
439 record the existence of a feature with a "1" value:
441 #define HAVE_FEATURE 1
443 Instead of printing the line without a "1", as it used to:
447 This should not cause any problems in the normal use of "#ifdef
448 HAVE_{FEATURE}" statements interpreted by a C preprocessor, but
449 might cause a compatibility issue if a script or other utility
450 looks for an exact match of the previous text.
452 Please note the following planned, future changes:
454 -- THE Options OBJECT AND RELATED FUNCTIONS WILL BE DEPRECATED
456 The Options object is being replaced by a new Variables
457 object, which uses a new Variables.AddVariable() method
458 where the previous interface used Options.AddOptions().
460 Similarly, the following utility functions are being replaced
461 by the following similarly-named functions:
463 BoolOption() BoolVariable()
464 EnumOption() EnumVariable()
465 ListOption() ListVariable()
466 PackageOption() PackageVariable()
467 PathOption() PathVariable()
469 And also related, the options= keyword argument when creating
470 construction environments with the Environment() functions is
471 being replaced with a variables= keyword argument.
473 In some future release a deprecation warning will be added to
474 existing uses of the Options object, its methods, the above
475 utility functions, and the options= keyword argument of the
476 Environment() function. At some point after the deprecation
477 warning is added, the Options object, related functions and
478 options= keyword argument will be removed entirely.
480 You can prepare for this by changing all your uses of the Options
481 object and related functions to the Variables object and the new
482 function names, and changing any uses of the options= keyword
483 argument to variables=.
485 NOTE: CONVERTING TO USING THE NEW Variables OBJECT OR THE
486 RELATED *Variable() FUNCTIONS, OR USING THE NEW variable=
487 KEYWORD ARGUMENT, IS NOT BACKWARDS COMPATIBLE TO VERSIONS OF
488 SCons BEFORE 0.98. YOUR SConscript FILES WILL NOT WORK ON
489 EARLIER VERSIONS OF SCons AFTER MAKING THIS CHANGE.
491 If you change SConscript files in software that you make available
492 for download or otherwise distribute, other users may try to
493 build your software with an earlier version of SCons that does
494 not have the Variables object or related *Variable() functions.
495 We recommend preparing for this in one of two ways:
497 -- Make your SConscript files backwards-compatible by
498 modifying your calls with Python try:-except: blocks
502 vars = Variables('custom.py', ARGUMENTS)
504 BoolVariable('WARNINGS', 'cmopile with -Wall', 1),
505 EnumVariable('DEBUG', 'debug version', 'no'
506 allowed_values=('yes', 'no', 'full'),
507 map={}, ignorecase=0),
508 ListVariable('SHAREDLIBS',
509 'libraries to build shared',
511 names = list_of_libs),
512 PackageVariable('X11',
515 PathVariable('QTDIR', 'root of Qt', qtdir),
518 vars = Options('custom.py', ARGUMENTS)
520 BoolOption('WARNINGS', 'cmopile with -Wall', 1),
521 EnumOption('DEBUG', 'debug version', 'no'
522 allowed_values=('yes', 'no', 'full'),
523 map={}, ignorecase=0),
524 ListOption('SHAREDLIBS',
525 'libraries to build shared',
527 names = list_of_libs),
531 PathOption('QTDIR', 'root of Qt', qtdir),
534 Additionally, you can check for availability of the new
535 variables= keyword argument as follows:
538 env = Environment(variables=vars)
540 env = Environment(options=vars)
542 (Note that we plan to maintain the existing Options object
543 name for some time, to ensure backwards compatibility,
544 so in practice it may be easier to just continue to use
545 the old name until you're reasonably sure you won't have
546 people trying to build your software with versions of
547 SCons earlier than 0.98.1.)
549 -- Use the EnsureSConsVersion() function to provide a
550 descriptive error message if your SConscript files
551 are executed by an earlier version of SCons:
553 EnsureSConsVersion(0, 98, 1)
555 -- THE BuildDir() METHOD AND FUNCTION WILL BE DEPRECATED
557 The env.BuildDir() method and BuildDir() function are being
558 replaced by the new env.VariantDir() method and VariantDir()
561 In some future release a deprecation warning will be added
562 to existing uses of the env.BuildDir() method and BuildDir()
563 function. At some point after the deprecation warning, the
564 env.Builder() method and BuildDir() function will either
565 be removed entirely or have their behavior changed.
567 You can prepare for this by changing all your uses of the
568 env.BuildDir() method to env.VariantDir() and uses of the
569 global BuildDir() function to VariantDir(). If you use a
570 named keyword argument of "build_dir" when calling
571 env.BuildDir() or BuildDir():
573 env.BuildDir(build_dir='opt', src_dir='src')
575 The keyword must be changed to "variant_dir":
577 env.VariantDir(variant_dir='opt', src_dir='src')
579 NOTE: CHANGING USES OF env.BuildDir() AND BuildDir() to
580 env.VariantDir() AND VariantDir() IS NOT BACKWARDS COMPATIBLE
581 TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES
582 WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING
585 If you change SConscript files in software that you make
586 available for download or otherwise distribute, other users
587 may try to build your software with an earlier version of
588 SCons that does not have the env.VariantDir() method or
589 VariantDir() fnction. We recommend preparing for this in
592 -- Make your SConscript files backwards-compatible by
593 including the following code near the beginning of your
594 top-level SConstruct file:
596 import SCons.Environment
598 SCons.Environment.Environment.VariantDir
599 except AttributeError:
600 SCons.Environment.Environment.VariantDir = \
601 SCons.Environment.Environment.BuildDir
603 -- Use the EnsureSConsVersion() function to provide a
604 descriptive error message if your SConscript files
605 are executed by an earlier version of SCons:
607 EnsureSConsVersion(0, 98)
609 -- THE SConscript() "build_dir" KEYWORD ARGUMENT WILL BE DEPRECATED
611 The "build_dir" keyword argument of the SConscript function
612 and env.SConscript() method are being replaced by a new
613 "variant_dir" keyword argument.
615 In some future release a deprecation warning will be added
616 to existing uses of the SConscript()/env.SConscript()
617 "build_dir" keyword argument. At some point after the
618 deprecation warning, support for this keyword argument will
621 You can prepare for this by changing all your uses of the
622 SConscript()/env.SConscript() 'build_dir" keyword argument:
624 SConscript('src/SConscript', build_dir='opt')
626 To use the new "variant_dir" keyword argument:
628 SConscript('src/SConscript', variant_dir='opt')
630 NOTE: USING THE NEW "variant_dir" KEYWORD IS NOT BACKWARDS
631 COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript
632 FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER
635 If you change SConscript files in software that you make
636 available for download or otherwise distribute, other users
637 may try to build your software with an earlier version of
638 SCons that does not support the "variant_dir" keyword.
640 If you can insist that users use a recent version of SCons
641 that supports "variant_dir", we recommend using the
642 EnsureSConsVersion() function to provide a descriptive error
643 message if your SConscript files are executed by an earlier
646 EnsureSConsVersion(0, 98)
648 If you want to make sure that your SConscript files will
649 still work with earlier versions of SCons, then your best
650 bet is to continue to use the "build_dir" keyword until the
651 support is removed (which, in all likelihood, won't happen
652 for quite some time).
654 -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
656 Several internal variable names in SCons.Defaults for various
657 pre-made default Scanner objects have been deprecated and will
658 be removed in a future revision. In their place are several new
659 global variable names that are now part of the publicly-supported
662 NEW NAME DEPRECATED NAME
663 -------- ----------------------------
664 CScanner SCons.Defaults.CScan
665 DSCanner SCons.Defaults.DScan
666 SourceFileScanner SCons.Defaults.ObjSourceScan
667 ProgramScanner SCons.Defaults.ProgScan
669 Of these, only ObjSourceScan was probably used at all, to add
670 new mappings of file suffixes to other scanners for use by the
671 Object() Builder. This should now be done as follows:
673 SourceFileScanner.add_scanner('.x', XScanner)
675 -- THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY
677 The env.Copy() method (to make a copy of a construction
678 environment) is being replaced by the env.Clone() method.
680 As of SCons 0.98, a deprecation warning has been added to
681 current uses of the env.Copy() method. At some point in
682 the future, the env.Copy() method will either be removed
683 entirely or have its behavior changed.
685 You can prepare for this by changing all your uses of env.Copy()
686 to env.Clone(), which has the exact same calling arguments.
688 NOTE: CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE
689 YOUR SConscript FILES NOT WORK ON VERSIONS OF SCons BEFORE
692 If you change SConscript files in software that you make
693 available for download or otherwise distribute, other users
694 may try to build your software with an earlier version of
695 SCons that does not have the env.Clone() method. We recommend
696 preparing for this in one of two ways:
698 -- Make your SConscript files backwards-compatible by
699 including the following code near the beginning of your
700 top-level SConstruct file:
702 import SCons.Environment
704 SCons.Environment.Environment.Clone
705 except AttributeError:
706 SCons.Environment.Environment.Clone = \
707 SCons.Environment.Environment.Copy
709 -- Use the EnsureSConsVersion() function to provide a
710 descriptive error message if your SConscript files
711 are executed by an earlier version of SCons:
713 EnsureSConsVersion(0, 96, 93)
715 SCons is developed with an extensive regression test suite, and a
716 rigorous development methodology for continually improving that suite.
717 Because of this, SCons is of sufficient quality that you can use it
718 for real work. The "beta" status of the release reflects that we
719 still may change interfaces in future releases, which may require
720 modifications to your SConscript files. We strive to hold these
721 changes to a minimum.
723 Nevertheless, please heed the following disclaimers:
725 - Please report any bugs or other problems that you find to our bug
726 tracker at our SourceForge project page:
728 http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
730 We have a reliable bug-fixing methodology already in place and
731 strive to respond to problems relatively quickly.
733 - Documentation is spottier than we'd like. You may need to dive
734 into the source code to figure out how to do something. Asking
735 questions on the scons-users mailing list is also welcome. We
736 will be addressing the documentation in upcoming releases, but
737 would be more than glad to have your assistance in correcting this
740 In particular, the "SCons Design" documentation on the SCons web
741 site is currently out of date, as we made significant changes to
742 portions of the interface as we figured out what worked and what
743 didn't during implementation.
745 - There may be performance issues. Improving SCons performance
746 is an ongoing priority. If you still find the performance
747 unacceptable, we would very much like to hear from you and learn
748 more about your configuration so we can optimize the right things.
750 - Error messages don't always exist where they'd be helpful.
751 Please let us know about any errors you ran into that would
752 have benefitted from a (more) descriptive message.
754 KNOWN PROBLEMS IN THIS RELEASE:
756 For a complete list of known problems, consult the SCons Issue Tracker
759 http://scons.tigris.org/project_issues.html
761 - Support for parallel builds (-j) does not work on WIN32 systems
762 prior to *official* Python release 2.2 (not 2.2 pre-releases).
764 Prior to Python 2.2, there is a bug in Python's Win32
765 implementation such that when a thread spawns an external command,
766 it blocks all threads from running. This breaks the SCons
767 multithreading architecture used to support -j builds.
769 We have included a patch file, os_spawnv_fix.diff, that you can
770 use if you you want to fix your version of Python to support
771 parallel builds in SCons.
773 - Again, the "SCons Design" documentation on the SCons web
774 site is currently out of date. Take what you read there with a
777 - On Win32 systems, you must put a space between the redirection
778 characters < and >, and the specified files (or construction
779 variable expansions):
781 command < $SOURCE > $TARGET
783 If you don't supply a space (for example, "<$SOURCE"), SCons will
784 not recognize the redirection.
786 - MSVC .res files are not rebuilt when icons change.
788 - The -c option does not clean up .sconsign files or directories
789 created as part of the build, and also does not clean up
790 SideEffect files (for example, Visual Studio .pdb files).
792 - When using multiple Repositories, changing the name of an include
793 file can cause an old version of the file to be used.
795 - There is currently no way to force use of a relative path (../*)
796 for directories outside the top-level SConstruct file.
798 - The Jar() Builder will, on its second or subsequent invocation,
799 package up the .sconsign files that SCons uses to track signatures.
800 You can work around this by using the SConsignFile() function
801 to collect all of the .sconsign information into a single file
802 outside of the directory being packaged by Jar().
804 - SCons does not currently have a way to detect that an intermediate
805 file has been corrupted from outside and should be rebuilt.
807 - Unicode characters in path names do not work in all circumstances.
809 - SCons does not currently automatically check out SConstruct or
810 SConscript files from SCCS, RCS or BitKeeper.
812 - No support yet for the following planned command-line options:
814 -d -e -l --list-actions --list-derived --list-where
815 -o --override -p -r -R -w --write-filenames
816 -W --warn-undefined-variables
820 Thank you for your interest, and please let us know how we can help
821 improve SCons for your needs.
824 knight at baldmt dot com
825 http://www.baldmt.com/~knight/
827 With plenty of help from the SCons Development team: