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
23 RELEASE 0.97.0d200709XX - XXX
25 This is the eighth beta release of SCons. Please consult the
26 CHANGES.txt file for a list of specific changes since last release.
28 Please note the following important changes since release 0.97.0d20070809:
30 -- "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR
32 The default behavior of SCons is now to use the MD5 checksum of
33 all file contents to decide if any files have changed and should
34 cause rebuilds of their source files. This means that SCons may
35 decide not to rebuild "downstream" targets if a a given input
36 file is rebuilt to the exact same contents as the last time.
37 The old behavior may preserved by explicity specifying:
39 TargetSignatures("build")
41 In any of your SConscript files.
43 -- TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM
45 For all targets built by calling external commands (such as a
46 compiler or other utility), SCons now adds an implicit dependency
47 on the command(s) used to build the target.
49 This will cause rebuilds of all targets built by external commands
50 when running SCons in a tree built by previous version of SCons,
51 in order to update the recorded signatures.
53 The old behavior of not having targets depend on the external
54 commands that build them can be preserved by setting a new
55 $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a
58 env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0)
60 or by adding Ignore() calls for any targets where the behavior
63 Ignore('/usr/bin/gcc', 'foo.o')
65 Both of these settings are compatible with older versions
68 -- CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS
70 If you change the SourceSignature() value from 'timestamp' to
71 'MD5', SCons will now rebuild targets that were already up-to-date
72 with respect to their source files.
74 This will happen because SCons did not record the content
75 signatures of the input source files when the target was last
76 built--it only recorded the timestamps--and it must record them
77 to make sure the signature information is correct. However,
78 the content of source files may have changed since the last
79 timestamp build was performed, and SCons would not have any way to
80 verify that. (It would have had to open up the file and record
81 a content signature, which is one of the things you're trying to
82 avoid by specifying use of timestamps....) So in order to make
83 sure the built targets reflect the contents of the source files,
84 the targets must be rebuilt.
86 Change the SourceSignature() value from 'MD5' to 'timestamp'
87 should correctly not rebuild target files, because the timestamp
88 of the files is always recorded.
90 In previous versions of SCons, changing the SourceSignature()
91 value would lead to unpredictable behavior, usually including
94 -- THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY
96 The Return() function now immediately stops processing the
97 SConscript file in which it appears and returns the values of the
98 variables named in its arguments. It used to continue processing
99 the rest of the SConscript file, and then return the values of the
100 specified variables at the point the Return() function was called.
102 The old behavior may be requested by adding a "stop=False"
103 keyword argument to the Return() call:
105 Return('value', stop=False)
107 The "stop=" keyword argument is *not* compatible with SCons
108 versions 0.97.0d20070809 or earlier.
110 Please note the following important changes since release 0.97:
112 -- env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS
114 The env.CacheDir() method now only causes derived files to be
115 retrieved from the specified cache directory for targets built
116 with the specified specified construction environment ("env").
118 Previously, any call to env.CacheDir() or CacheDir() would modify
119 a global setting and cause all built targets to be retrieved
120 from the specified cache directory. This behavior was changed so
121 that env.CacheDir() would be consistent with other construction
122 environment methods, which only affect targets built with the
123 specified construction environment.
125 The old behavior of changing the global behavior may be preserved
126 by changing any env.CacheDir() calls to:
128 CacheDir('/path/to/cache/directory')
130 The above change is backwards-compatible and works in all earlier
131 versions of SCons that support CacheDir().
133 -- INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED
135 The interpretation of source arguments (files) without suffixes
136 has changed in one specific configuration.
138 Previously, if a Builder had a src_suffix specified (indicating
139 that source files without suffixes should have that suffix
140 appended), the suffix would only be applied to suffix-less source
141 arguments if the Builder did *not* have one or more attached
142 source Builders (that is, the Builder was not a "multi-stage"
143 Builder). So in the following configuration:
145 build_foo = Builder(src_suffix = '.foo')
146 build_bar = Builder(src_suffix = '.bar',
147 src_builder = build_bar)
149 env = Environment(BUILDERS = {
154 env.Foo('tgt1', 'src1')
155 env.Bar('tgt2', 'src2')
157 SCons would have expected to find a source file 'src1.foo' for the
158 env.Foo() call, but a source file 'src2' for the env.Bar() call.
160 This behavior has now been made consistent, so that the two
161 above calls would expect source files named 'src1.foo' and
162 'src2.bar', respectively.
164 Note that, if genuinely desired, the old behavior of building
165 from a source file without a suffix at all (when the Builder has
166 a src_suffix *and* a src_builder) can be specified explicity by
167 turning the string into a File Node directly:
169 env.Bar('tgt2', File('src2'))
171 The above use of File() is backwards-compatible and will work
172 on earlier versions of SCons.
174 -- THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED
176 On Solaris systems, SCons now adds the "/opt/SUNWspro/bin"
177 directory to the default execution $PATH variable before the
178 "/usr/ccs/bin" directory. This was done to reflect the fact
179 that /opt/SUNWspro/ is the default for SUN tools, but it may
180 cause a different compiler to be used if you have compilers
181 installed in both directories.
183 -- GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1"
185 When generating a "config.h" file, SCons now defines values that
186 record the existence of a feature with a "1" value:
188 #define HAVE_FEATURE 1
190 Instead of printing the line without a "1", as it used to:
194 This should not cause any problems in the normal use of "#ifdef
195 HAVE_{FEATURE}" statements interpreted by a C preprocessor, but
196 might cause a compatibility issue if a script or other utility
197 looks for an exact match of the previous text.
199 Please note the following important changes since release 0.96.93:
201 -- THE --debug=memoizer OPTION NOW REQUIRES PYTHON 2.2 OR LATER
203 The --debug=memoizer option now prints a warning message and
204 does nothing if SCons is run on a version of Python that does
205 not support metaclasses (earlier than Python 2.2).
207 -- THE --debug=nomemoizer OPTION DOES NOTHING AND IS NOW DEPRECATED
209 The --debug=nomemoizer no longer does anything and instead
210 now generates a warning message about being deprecated. The
211 --debug=nomemoizer will be removed completely in a future release.
213 Please note the following important changes since release 0.96.91:
215 -- /opt/bin AND /sw/bin ADDED TO DEFAULT EXECUTION PATH VARIABLES
217 On all POSIX systems, the default execution PATH variable has had
218 the /opt/bin directory added after the /usr/local/bin directory
219 and before /bin and /usr/bin directories. This may cause SCons
220 to find and/or use different compilers, linkers, etc., if you
221 have any same-named utilities installed in /opt/bin that SCons
222 previously found in /bin or /usr/bin.
224 On Mac OS X (Darwin) systems, the /sw/bin directory has been added
225 to the end of the default execution PATH. This may cause SCons
226 to find compilers, linkers and other utilities it previously did
227 not, although it should not otherwise change existing behavior.
229 -- Configure.Checklib() ARGUMENTS HAVE CHANGED TO MATCH DOCUMENTATION
231 The order of the arguments to the Configure.CheckLib() function
232 has changed to put the "autoadd" keyword argument last, matching
233 the documentation in the man page. This could cause problems
234 for any calls to Configure.Checklib() that were relying on the
235 order of the arguments. Specifying all arguments as keyword
236 arguments will work on both older and newer versions of SCons.
238 -- env.subst() NO LONGER EXPANDS $TARGET, $SOURCES, etc. BY DEFAULT
240 Calls to the env.subst() method to interpolate construction
241 variables in strings no longer automatically expand the special
242 variables $TARGET, $TARGETS, $SOURCE and $SOURCES. The keyword
243 variables "target" and "source" must now be set to the lists
244 of target and source files to be used in expansion of those
245 variables, when desired.
247 This is most likely necessary for any env.subst() calls within
248 a Python function being used as an SCons action for a Builder:
250 def build_it(env, target, source):
251 env.subst('$STRING', target=targets, source=sources)
252 MyBuilder = Builder(action=build_it)
254 The "target" and "source" keyword arguments are backwards
255 compatible and can be added to SConscript files without breaking
256 builds on systems using older SCons releases.
258 -- INTERNAL FUNCTIONS AND CLASSES HAVE MOVED FROM SCons.Util
260 All internal functions and classes related to string substitution
261 have been moved out of the SCons.Util module into their own
262 SCons.Subst module. The following classes have been moved:
270 And the following functions have moved:
279 If your SConscript files have been using any of these function
280 directly from the SCons.Util module (which they ultimately should
281 not be!), you will need to modify them.
283 Please note the following important changes since release 0.96.90:
285 -- SIGNATURES ARE NOW STORED IN AN SConsignFile() BY DEFAULT,
286 CAUSING LIKELY REBUILDS; SPECIAL NOTE CONCERNING INTERACTION
289 The default behavior has been changed to store signature
290 information in a single .sconsign.dblite file in the top-level
291 SConstruct file. This will cause rebuilds on upgrade to 0.97,
292 unless you were already calling the SConsignFile() function in
293 your SConscript files.
295 The previous default behavior was to store signature information
296 in a .sconsign file in each directory that contained target
297 files that SCons knew about. The old behavior may be preserved
302 in any SConscript file.
304 If you are using the Repository feature, and are not already
305 using the SConsignFile() function in your build, you *must*
306 add "SConsignFile(None)" to your build configuration to keep
307 interoperating with an existing Repository that uses the old
308 behavior of a .sconsign file in each directory. Alternatively,
309 you can rebuild the Repository with the new default behavior.
311 -- OTHER SIGNATURE CHANGES WILL CAUSE LIKELY REBUILDS AFTER UPGRADE
313 This release adds several changes to the signature mechanism that
314 will cause SCons to rebuild most configurations after upgrading
315 (and when switching back to an earlier release from 0.97).
318 -- NORMALIZED PATHS IN SConsignFile() DATABASES ON WINDOWS
320 When using an SConsignFile() database, instead of
321 individual .sconsign files in each directory, the path
322 names are stored in normalized form with / (forward slash)
323 separating the elements. This may cause rebuilds when
324 upgrading to SCons 0.97 on Windows systems with hierarchical
325 build configurations.
327 -- STORED DEPENDENCY PATHS ARE NOW RELATIVE TO THE TARGET
329 SCons used to store the paths of all source files and
330 dependencies relative to the top-level SConstruct directory.
331 It now stores them relative to the directory of the
332 associated target file. This makes it possible to use
333 content signatures to subdivide a dependency tree without
334 causing unnecessary rebuilds due to an intermediate file in
335 one build being treated as a source file in a nother build.
337 This is a step towards making it possible to write a
338 hierarchy of SConstruct files that allow developers
339 to build just one portion of a tree wherever there's an
340 SConstruct file. (Note that this would still require some
341 specific code at the top of each SConstruct file, but we
342 hope to make this an easier/more naturally supported thing
345 -- PYTHON FUNCTION ACTION SIGNATURES HAVE CHANGED TO AVOID
346 FUTURE REBUILDS AND REBUILDS BETWEEN PYTHON VERSIONS
348 SCons Actions for Python functions use the function's
349 byte code to generate their signature. The byte code
350 in older versions of Python includes indications of the
351 line numbers at which the function's code appeared in
352 its original source file, which means that changes in the
353 location of an otherwise unmodified Python function would
354 trigger rebuilds. The line number byte codes are now
355 removed from the signature, which will cause any targets
356 built by Python function Actions (including various
357 pre-supplied SCons Actions) to be rebuilt.
359 -- REMOVED CONVERSION FROM PRE-0.96 .sconsign FORMATS
361 Because this release involves so many other signature
362 changes that cause rebuilds, the support for automatically
363 converting signature information from .sconsign files
364 written by SCons versions prior to 0.96 has been removed.
366 -- ORDER OF -o FLAGS ON CERTAIN LINK COMMAND LINES HAS CHANGED
368 The -o flag that specifies an output file has been moved
369 on certain linker command lines to place it consistently
370 right after the link command itself. This will cause
371 recompilation of target files created by these changed
374 -- F95 AND F90 COMPILERS ARE NOW PREFERRED OVER F77
376 SCons now searches for Fortran 95 and Fortran 90 compilers first
377 in preference to Fortran 77. This may result in a different
378 Fortran compiler being used by default, although as Fortran 95 and
379 Fortran 90 are backwards compatible with Fortran 77, this should
380 not cause problems for standards-compliant Fortran programs.
381 On systems that have multiple versions of Fortran installed,
382 the Fortran 77 compiler may be explicitly selected by specifying
383 it when creating the construction environment:
385 env = Environment(tools = ['default', 'f77'])
387 -- SOLARIS DEFAULT SHARED OBJECT PREFIXES AND SUFFIXES HAVE CHANGED
389 On Solaris, SCons now builds shared objects from C and C++ source
390 files with a default prefix of "so_" and a default suffix of ".o".
391 The previous default suffix of ".os" caused problems when trying
392 to use SCons with Sun WorkShop.
394 -- CACHED Configure() RESULTS ARE STORED IN A DIFFERENT FILE
396 The Configure() subsystem now stores its cached results in a
397 different file. This may cause configuration tests to be re-run
398 the first time after you install 0.97.
400 -- setup.py INSTALLS VERSION-NUMBERED SCRIPTS AND DIRS BY DEFAULT
402 The setup.py script has been changed to always install SCons in
403 a version-numbered directory (e.g. /usr/local/lib/scons-0.97
404 or D:\Python23\scons-0.97) and with a version-numbered script
405 name (scons-0.97) in addition to the usual installation of an
406 "scons" script name. A number of new setup.py options allow
407 control over what does or does not get installed, and where.
408 See the README.txt or README files for additional information.
410 -- setup.py NOW INSTALLS MAN PAGES ON UNIX AND Linux SYSTEMS
412 The SCons setup.py script now installs the "scons.1" and
413 "sconsign.1" man pages on UNIX and Linux systems. A
416 -- BUILDERS RETURN A LIST-LIKE OBJECT, NOT A REGULAR LIST
418 Builder calls now return an object that behaves like a list
419 (and which provides some other functionality), not an underlying
420 Python list. In general, this should not cause any problems,
421 although it introduces a subtle change in the following behavior:
423 obj += env.Object('foo.c')
425 If "obj" is a regular Python list, Python will no longer update
426 the "obj" in place, because the return value from env.Object()
427 is no longer the same type. Python will instead allocate a
428 new object and assign the local variable "obj" to it. If "obj"
429 is defined in an SConscript file that calls another SConscript
430 file containing the above code, "obj" in the first SConscript
431 file will not contain the object file nodes created by the
434 You can guarantee that a list will be updated in place regardless
435 of which SConscript file defines it and which adds to it by
436 using the list append() method as follows:
438 obj.append(env.Object('foo.c'))
440 Please note the following important changes since release 0.96.1:
442 -- DIRECTORY TREES ARE NO LONGER AUTOMATICALLY SCANNED FOR CHANGES
444 Custom builders and Command() calls that accept directories as
445 source arguments no longer scan entire on-disk directory trees by
446 default. This means that their targets will not be automatically
447 rebuilt if a file changes on disk *unless* SCons already knows
448 about the file from a specific Builder or File() call. Note that
449 the targets will still be rebuilt correctly if a file changes
450 that SCons already knows about due to a Builder or other call.
452 The existing behavior of scanning on-disk directory trees for
453 any changed file can be maintained by passing the new DirScanner
454 global directory scanner as the source_scanner keyword argument
457 bld = Builder("build < $SOURCE > $TARGET",
458 source_scanner = DirScanner)
460 The same keyword argument can also be supplied to any Command()
461 calls that need to scan directory trees on-disk for changed files:
463 env.Command("archive.out", "directory",
464 "archiver -o $TARGET $SOURCE",
465 source_scanner = DirScanner)
467 This change was made because scanning directories by default
468 could cause huge slowdowns if a configurable directory like /usr
469 or /usr/local was passed as the source to a Builder or Command()
470 call, in which case SCons would scan the entire directory tree.
472 -- ParseConfig() METHOD ADDS LIBRARY FILE NAMES TO THE $LIBS VARIABLE
474 The ParseConfig() method now adds library file names returned
475 by the specified *-config command to the $LIBS construction
476 variable, instead of returning them (the same way it handles
479 -- ParseConfig() METHOD DOESN'T ADD DUPLICATES TO CONSTRUCTION VARIABLES
481 By default, the ParseConfig() method now avoids adding duplicate
482 entries to construction variables. The old behavior may be
483 specified using a new "unique=0" keyword argument.
485 -- WINDOWS %TEMP% and %TMP% VARIABLES ARE PROPAGATED AUTOMATICALLY
487 The %TEMP% and %TMP% external environment variables are now
488 propagated automatically to the command execution environment on
491 -- OUTPUT OF Configure() SUBSYSTEM CHANGED SLIGHTLY
493 The Configure() subsystem now reports tests results as "yes" and
494 "no" instead of "ok" and "failed." This might interfere with any
495 scripts that automatically parse the Configure() output from SCons.
497 -- VISUAL STUDIO ATL AND MFC DIRECTORIES NOT ADDED BY DEFAULT
499 When compiling with Microsoft Visual Studio, SCons no longer
500 adds the ATL and MFC directories to the INCLUDE and LIB
501 environment variables by default. If you want these directories
502 included in your environment variables, you should now set the
503 $MSVS_USE_MFC_DIRS *construction* variable when initializing
506 env = Environment(MSVS_USE_MFC_DIRS = 1)
508 -- DEPRECATED GLOBAL FUNCTIONS HAVE BEEN REMOVED
510 The following deprecated global functions have been removed:
511 ParseConfig(), SetBuildSignatureType(), SetContentSignatureType(),
512 SetJobs() and GetJobs().
514 -- DEPRECATED "validater" KEYWORD HAS BEEN REMOVED
516 The deprecated "validater" keyword to the Options.Add() method
519 Please note the following important changes since release 0.95:
521 -- BUILDERS NOW ALWAYS RETURN A LIST OF TARGETS
523 All Builder calls (both built-in like Program(), Library(),
524 etc. and customer Builders) now always return a list of target
525 Nodes. If the Builder only builds one target, the Builder
526 call will now return a list containing that target Node, not
527 the target Node itself as it used to do.
529 This change should be invisibile to most normal uses of the
530 return values from Builder calls. It will cause an error if the
531 SConscript file was performing some direct manipulation of the
532 returned Node value. For example, an attempt to print the name
533 of a target returned by the Object() Builder:
535 target = Object('foo.c')
539 Will now need to access the first element in the list returned by
542 target = Object('foo.c')
546 This change was introduced to make the data type returned by Builder
547 calls consistent (always a list), regardless of platform or number
550 -- DEFAULT SConsignFile() DATABASE SCHEME HAS CHANGED
552 The SConsignFile() function now uses an internally-supplied
553 SCons.dblite module as the default DB scheme for the .sconsign file.
554 If you are using the SConsignFile() function without an explicitly
555 specified dbm_module argument, this will cause all of your targets
556 to be recompiled the first time you use SCons 0.96. To preserve the
557 previous behavior, specify the "anydbm" module explicitly:
560 SConsignFile('.sconsign_file_name', anydbm)
562 -- INTERNAL .sconsign FILE FORMAT HAS CHANGED
564 The internal format of .sconsign files has been changed. This might
565 cause warnings about "ignoring corrupt .sconsign files" and rebuilds
566 when you use SCons 0.96 for the first time in a tree that was
567 previously built with SCons 0.95 or earlier.
569 -- INTERFACE CHANGE OF scan_check FUNCTION TO CUSTOM SCANNERS
571 The scan_check function that can be supplied to a custom Scanner now
572 must take two arguments, the Node to be checked and a construction
573 environment. It previously only used the Node as an argument.
575 -- DEFAULT SCANNERS NO LONGER HEED INTERNAL Scanner.add_skey() METHOD
577 The internal Scanner.add_skey() method no longer works for the
578 default scanners, which now use construction variables to hold their
579 lists of suffixes. If you had a custom Tool specification that was
580 reaching into the internals in this way to add a suffix to one of
581 the following scanner, you must now add the suffix to a construction
582 environment through which you plan to call the scanner, as follows:
584 CScan.add_skey('.x') => env.Append(CPPSUFFIXES = ['.x'])
585 DScan.add_skey('.x') => env.Append(DSUFFIXES = ['.x'])
586 FortranScan.add_skey('.x') => env.Append(FORTRANSUFFIXES = ['.x'])
588 -- KEYWORD ARGUMENTS TO Builder() HAVE BEEN REMOVED
590 The "node_factory" and "scanner" keyword arguments to the Builder()
591 function have been removed. In their place, the separate and more
592 flexible "target_factory," "source_factory," "target_scanner" and
593 "source scanner" keywords should be used instead.
595 -- ALL-DIGIT FILE "EXTENSIONS" ARE NOW PART OF THE FILE BASENAME
597 SCons now treats file "extensions" that contain all digits (for
598 example, "file.123") as part of the file basename, for easier
599 handling of version numbers in the names of shared libraries
600 and other files. Builders will now add their file extensions to
601 file names specified with all-digit extensions. If you need to
602 generate a file with an all-digit extension using a Builder that
603 adds a file extension, you can preserve the previous behavior by
604 wrapping the file name in a File() call.
606 -- Append()/Prepend() METHODS CHANGED WHEN USING UserList OBJECTS
608 The behavior of the env.Append() and env.Prepend() methods has
609 changed when appending a string value to a UserList, or vice versa.
610 They now behave like normal Python addition of a string to
611 a UserList. Given an initialization and an env.Append() call like:
613 env = Environment(VAR1=UserList(['foo']), VAR2='foo')
614 env.Append(VAR1='bar', VAR2=UserList(['bar'])
616 The resulting values of $VAR1 and $VAR2 will now be ['foo', 'b',
617 'a', 'r'] and ['f', 'o', 'o', 'bar'], respectively. This is because
618 Python UserList objects treat strings as sequences of letters when
619 adding them to the value of the UserList.
621 The old behavior of yielding $VAR1 and $VAR2 values of ['foo',
622 'bar'] when either variable is a UserList object now requires that
623 the string variables be enclosed in a list:
625 env = Environment(VAR1=UserList(['foo']), VAR2=['foo'])
626 env.Append(VAR1='bar', VAR2=UserList(['bar']))
628 Note that the SCons behavior when appending to normal lists has
629 *not* changed, and the behavior of all of the default values that
630 SCons uses to initialize all construction variables has *not*
631 changed. This change *only* affects any cases where you explicitly
632 use UserList objects to initialize or append to a variable.
634 Please note the following planned, future changes:
636 -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
638 Several internal variable names in SCons.Defaults for various
639 pre-made default Scanner objects have been deprecated and will
640 be removed in a future revision. In their place are several new
641 global variable names that are now part of the publicly-supported
644 NEW NAME DEPRECATED NAME
645 -------- ----------------------------
646 CScanner SCons.Defaults.CScan
647 DSCanner SCons.Defaults.DScan
648 SourceFileScanner SCons.Defaults.ObjSourceScan
649 ProgramScanner SCons.Defaults.ProgScan
651 Of these, only ObjSourceScan was probably used at all, to add
652 new mappings of file suffixes to other scanners for use by the
653 Object() Builder. This should now be done as follows:
655 SourceFileScanner.add_scanner('.x', XScanner)
657 -- THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY
659 The env.Copy() method (to make a copy of a construction
660 environment) is being replaced by the env.Clone() method.
662 In some future release, a deprecation warning will be added
663 to current uses of the env.Copy() method. At some point after
664 the deprecation warning, the env.Copy() method will either be
665 removed entirely or have its behavior changed.
667 You can prepare for this by changing all your uses of env.Copy()
668 to env.Clone(), which has the exact same calling arguments.
670 NOTE: CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE YOUR
671 SConscript FILES NOT WORK ON EARLIER VERSIONS OF SCons.
673 If you change SConscript files in software that you make available
674 for download or otherwise distribute, other users may try to
675 build your software with an earlier version of SCons that does
676 not have the env.Clone() method. We recommend preparing for
677 this in one of two ways:
679 -- Make your SConscript files backwards-compatible by
680 including the following code near the beginning of your
681 top-level SConstruct file:
683 import SCons.Environment
685 SCons.Environment.Environment.Clone
686 except AttributeError:
687 SCons.Environment.Environment.Clone = \
688 SCons.Environment.Environment.Copy
690 -- Use the EnsureSConsVersion() function to provide a
691 descriptive error message if your SConscript files
692 are executed by an earlier version of SCons:
694 EnsureSConsVersion(0, 96, 93)
696 SCons is developed with an extensive regression test suite, and a
697 rigorous development methodology for continually improving that suite.
698 Because of this, SCons is of sufficient quality that you can use it
699 for real work. The "beta" status of the release reflects that we
700 still may change interfaces in future releases, which may require
701 modifications to your SConscript files. We strive to hold these
702 changes to a minimum.
704 Nevertheless, please heed the following disclaimers:
706 - Please report any bugs or other problems that you find to our bug
707 tracker at our SourceForge project page:
709 http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
711 We have a reliable bug-fixing methodology already in place and
712 strive to respond to problems relatively quickly.
714 - Documentation is spottier than we'd like. You may need to dive
715 into the source code to figure out how to do something. Asking
716 questions on the scons-users mailing list is also welcome. We
717 will be addressing the documentation in upcoming releases, but
718 would be more than glad to have your assistance in correcting this
721 In particular, the "SCons Design" documentation on the SCons web
722 site is currently out of date, as we made significant changes to
723 portions of the interface as we figured out what worked and what
724 didn't during implementation.
726 - There may be performance issues. Improving SCons performance
727 is an ongoing priority. If you still find the performance
728 unacceptable, we would very much like to hear from you and learn
729 more about your configuration so we can optimize the right things.
731 - Error messages don't always exist where they'd be helpful.
732 Please let us know about any errors you ran into that would
733 have benefitted from a (more) descriptive message.
735 KNOWN PROBLEMS IN THIS RELEASE:
737 For a complete list of known problems, consult the SCons Issue Tracker
740 http://scons.tigris.org/project_issues.html
742 - Support for parallel builds (-j) does not work on WIN32 systems
743 prior to *official* Python release 2.2 (not 2.2 pre-releases).
745 Prior to Python 2.2, there is a bug in Python's Win32
746 implementation such that when a thread spawns an external command,
747 it blocks all threads from running. This breaks the SCons
748 multithreading architecture used to support -j builds.
750 We have included a patch file, os_spawnv_fix.diff, that you can
751 use if you you want to fix your version of Python to support
752 parallel builds in SCons.
754 - Again, the "SCons Design" documentation on the SCons web
755 site is currently out of date. Take what you read there with a
758 - On Win32 systems, you must put a space between the redirection
759 characters < and >, and the specified files (or construction
760 variable expansions):
762 command < $SOURCE > $TARGET
764 If you don't supply a space (for example, "<$SOURCE"), SCons will
765 not recognize the redirection.
767 - MSVC .res files are not rebuilt when icons change.
769 - The -c option does not clean up .sconsign files or directories
770 created as part of the build, and also does not clean up
771 SideEffect files (for example, Visual Studio .pdb files).
773 - Switching content signatures from "MD5" to "timestamp" and back
774 again can cause unusual errors. These errors can be cleared up by
775 removing all .sconsign files.
777 - When using multiple Repositories, changing the name of an include
778 file can cause an old version of the file to be used.
780 - There is currently no way to force use of a relative path (../*)
781 for directories outside the top-level SConstruct file.
783 - The Jar() Builder will, on its second or subsequent invocation,
784 package up the .sconsign files that SCons uses to track signatures.
785 You can work around this by using the SConsignFile() function
786 to collect all of the .sconsign information into a single file
787 outside of the directory being packaged by Jar().
789 - SCons does not currently have a way to detect that an intermediate
790 file has been corrupted from outside and should be rebuilt.
792 - Unicode characters in path names do not work in all circumstances.
794 - SCons does not currently automatically check out SConstruct or
795 SConscript files from SCCS, RCS or BitKeeper.
797 - No support yet for the following planned command-line options:
799 -d -e -l --list-actions --list-derived --list-where
800 -o --override -p -r -R -w --write-filenames
801 -W --warn-undefined-variables
805 Thank you for your interest, and please let us know how we can help
806 improve SCons for your needs.
809 knight at baldmt dot com
810 http://www.baldmt.com/~knight/
812 With plenty of help from the SCons Development team: