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.96.96 - Thu, 12 Apr 2007 12:36:25 -0500
25 This is a pre-release for testing the eighth beta release of SCons.
26 Please consult the CHANGES.txt file for a list of specific changes
29 Please note the following important changes since release 0.96.93:
31 -- THE --debug=memoizer OPTION NOW REQUIRES PYTHON 2.2 OR LATER
33 The --debug=memoizer option now prints a warning message and
34 does nothing if SCons is run on a version of Python that does
35 not support metaclasses (earlier than Python 2.2).
37 -- THE --debug=nomemoizer OPTION DOES NOTHING AND IS NOW DEPRECATED
39 The --debug=nomemoizer no longer does anything and instead
40 now generates a warning message about being deprecated. The
41 --debug=nomemoizer will be removed completely in a future release.
43 Please note the following important changes since release 0.96.91:
45 -- /opt/bin AND /sw/bin ADDED TO DEFAULT EXECUTION PATH VARIABLES
47 On all POSIX systems, the default execution PATH variable has had
48 the /opt/bin directory added after the /usr/local/bin directory
49 and before /bin and /usr/bin directories. This may cause SCons
50 to find and/or different compilers, linkers, etc. if you have
51 any same-named utilities installed in /opt/bin that it previously
52 found in /bin or /usr/bin.
54 On Mac OS X (Darwin) systems, the /sw/bin directory has been added
55 to the end of the default execution PATH. This may cause SCons
56 to find compilers, linkers and other utilities it previously did
57 not, although it should not otherwise change existing behavior.
59 -- Configure.Checklib() ARGUMENTS HAVE CHANGED TO MATCH DOCUMENTATION
61 The order of the arguments to the Configure.CheckLib() function
62 has changed to put the "autoadd" keyword argument last, matching
63 the documentation in the man page. This could cause problems
64 for any calls to Configure.Checklib() that were relying on the
65 order of the arguments. Specifying all arguments as keyword
66 arguments will work on both older and newer versions of SCons.
68 -- env.subst() NO LONGER EXPANDS $TARGET, $SOURCES, etc. BY DEFAULT
70 Calls to the env.subst() method to interpolate construction
71 variables in strings no longer automatically expand the special
72 variables $TARGET, $TARGETS, $SOURCE and $SOURCES. The keyword
73 variables "target" and "source" must now be set to the lists
74 of target and source files to be used in expansion of those
75 variables, when desired.
77 This is most likely necessary for any env.subst() calls within
78 a Python function being used as an SCons action for a Builder:
80 def build_it(env, target, source):
81 env.subst('$STRING', target=targets, source=sources)
82 MyBuilder = Builder(action=build_it)
84 The "target" and "source" keyword arguments are backwards
85 compatible and can be added to SConscript files without breaking
86 builds on systems using older SCons releases.
88 -- INTERNAL FUNCTIONS AND CLASSES HAVE MOVED FROM SCons.Util
90 All internal functions and classes related to string substitution
91 have been moved out of the SCons.Util module into their own
92 SCons.Subst module. The following classes have been moved:
100 And the following functions have moved:
109 If your SConscript files have been using any of these function
110 directly from the SCons.Util module (which they ultimately should
111 not be!), you will need to modify them.
113 Please note the following important changes since release 0.96.90:
115 -- SIGNATURES ARE NOW STORED IN AN SConsignFile() BY DEFAULT,
116 CAUSING LIKELY REBUILDS; SPECIAL NOTE CONCERNING INTERACTION
119 The default behavior has been changed to store signature
120 information in a single .sconsign.dblite file in the top-level
121 SConstruct file. This will cause rebuilds on upgrade to 0.97,
122 unless you were already calling the SConsignFile() function in
123 your SConscript files.
125 The previous default behavior was to store signature information
126 in a .sconsign file in each directory that contained target
127 files that SCons knew about. The old behavior may be preserved
132 in any SConscript file.
134 If you are using the Repository feature, and are not already
135 using the SConsignFile() function in your build, you *must*
136 add "SConsignFile(None)" to your build configuration to keep
137 interoperating with an existing Repository that uses the old
138 behavior of a .sconsign file in each directory. Alternatively,
139 you can rebuild the Repository with the new default behavior.
141 -- OTHER SIGNATURE CHANGES WILL CAUSE LIKELY REBUILDS AFTER UPGRADE
143 This release adds several changes to the signature mechanism that
144 will cause SCons to rebuild most configurations after upgrading
145 (and when switching back to an earlier release from 0.97).
148 -- NORMALIZED PATHS IN SConsignFile() DATABASES ON WINDOWS
150 When using an SConsignFile() database, instead of individual
151 .sconsign files in each directory, the path names are
152 stored in normalized form with / (forward slash) separating
153 the elements. This may cause rebuilds on Windows systems
154 with hierarchical configurations.
156 -- STORED DEPENDENCY PATHS ARE NOW RELATIVE TO THE TARGET
158 SCons used to store the paths of all source files and
159 dependencies relative to the top-level SConstruct directory.
160 It now stores them relative to the directory of the
161 associated target file. This makes it possible to use
162 content signatures to subdivide a dependency tree without
163 causing unnecessary rebuilds due to an intermediate file in
164 one build being treated as a source file in a nother build.
166 This a step towards making it possible to write a hierarchy
167 of SConstruct files that allow developers to build just
168 one portion of a tree wherever there's an SConstruct file.
169 (Note that this would still require some specific code at
170 the top of each SConstruct file, but we hope to make this
171 an easier/more naturally supported thing in the future.)
173 -- PYTHON FUNCTION ACTION SIGNATURES HAVE CHANGED TO AVOID
174 FUTURE REBUILDS AND REBUILDS BETWEEN PYTHON VERSIONS
176 SCons Actions for Python functions use the functions byte
177 code to generate their signature. The byte code in older
178 versions of Python includes indications of the line numbers
179 at which the function's code appeared in its original
180 source file, which means that changes in the location of
181 an otherwise unmodified Python function would trigger
182 rebuilds. The line number byte codes are now removed
183 from the signature, which will cause any targets built by
184 Python function Actions (including various pre-supplied
185 SCons Actions) be rebuilt.
187 -- REMOVED CONVERSION FROM PRE-0.96 .sconsign FORMATS
189 Because this release involves so many other signature
190 changes that cause rebuilds, the support for automatically
191 converting signature information from .sconsign files
192 written by SCons versions prior to 0.96 has been removed.
194 -- ORDER OF -o FLAGS ON CERTAIN LINK COMMAND LINES HAS CHANGED
196 The -o flag that specifies an output file has been moved on
197 certain linker command lines to place it consistently after
198 the link command itself. This will cause recompilation
199 of target files created by these changed lines.
201 -- F95 AND F90 COMPILERS ARE NOW PREFERRED OVER F77
203 SCons now searches for Fortran 95 and Fortran 90 compilers first
204 in preference to Fortran 77. This may result in a different
205 Fortran compiler being used by default, although as Fortran 95 and
206 Fortran 90 are backwards compatible with Fortran 77, this should
207 not cause problems for standards-compliant Fortran programs.
208 On systems that have multiple versions of Fortran installed,
209 the Fortran 77 compiler may be explicitly selected by specifying
210 it when creating the construction environment:
212 env = Environment(tools = ['default', 'f77'])
214 -- SOLARIS DEFAULT SHARED OBJECT PREFIXES AND SUFFIXES HAVE CHANGED
216 On Solaris, SCons now builds shared objects from C and C++ source
217 files with a default prefix of "so_" and a default suffix of ".o".
218 The previous default suffix of ".os" caused problems when trying
219 to use SCons with Sun WorkShop.
221 -- CACHED Configure() RESULTS ARE STORED IN A DIFFERENT FILE
223 The Configure() subsystem now stores its cached results in a
224 different file. This may cause configuration tests to be re-run
225 the first time after you install 0.97.
227 -- setup.py INSTALLS VERSION-NUMBERED SCRIPTS AND DIRS BY DEFAULT
229 The setup.py script has been changed to always install SCons in
230 a version-numbered directory (e.g. /usr/local/lib/scons-0.97
231 or D:\Python23\scons-0.97) and with a version-numbered script
232 name (scons-0.97) in addition to the usual installation of an
233 "scons" script name. A number of new setup.py options allow
234 control over what does or does not get installed, and where.
235 See the README.txt or README files for additional information.
237 -- setup.py NOW INSTALLS MAN PAGES ON UNIX AND Linux SYSTEMS
239 The SCons setup.py script now installs the "scons.1" and
240 "sconsign.1" man pages on UNIX and Linux systems. A
243 -- BUILDERS RETURN A LIST-LIKE OBJECT, NOT A REGULAR LIST
245 Builder calls now return an object that behaves like a list
246 (and which provides some other functionality), not an underlying
247 Python list. In general, this should not cause any problems,
248 although it introduces a subtle change in the following behavior:
250 obj += env.Object('foo.c')
252 If "obj" is a regular Python list, Python will no longer update
253 the "obj" in place, because the return value from env.Object()
254 is no longer the same type. Python will instead allocate a
255 new object and assign the local variable "obj" to it. If "obj"
256 is defined in an SConscript file that calls another SConscript
257 file containing the above code, "obj" in the first SConscript
258 file will not contain the object file nodes created by the
261 You can guarantee that a list will be updated in place regardless
262 of which SConscript file defines it and which adds to it by
263 using the list append() method as follows:
265 obj.append(env.Object('foo.c'))
267 Please note the following important changes since release 0.96.1:
269 -- DIRECTORY TREES ARE NO LONGER AUTOMATICALLY SCANNED FOR CHANGES
271 Custom builders and Command() calls that accept directories as
272 source arguments no longer scan entire on-disk directory trees by
273 default. This means that their targets will not be automatically
274 rebuilt if a file changes on disk *unless* SCons already knows
275 about the file from a specific Builder or File() call. Note that
276 the targets will still be rebuilt correctly if a file changes
277 that SCons already knows about due to a Builder or other call.
279 The existing behavior of scanning on-disk directory trees for
280 any changed file can be maintained by passing the new DirScanner
281 global directory scanner as the source_scanner keyword argument
284 bld = Builder("build < $SOURCE > $TARGET",
285 source_scanner = DirScanner)
287 The same keyword argument can also be supplied to any Command()
288 calls that need to scan directory trees on-disk for changed files:
290 env.Command("archive.out", "directory",
291 "archiver -o $TARGET $SOURCE",
292 source_scanner = DirScanner)
294 This change was made because scanning directories by default
295 could cause huge slowdowns if a configurable directory like /usr
296 or /usr/local was passed as the source to a Builder or Command()
297 call, in which case SCons would scan the entire directory tree.
299 -- ParseConfig() METHOD ADDS LIBRARY FILE NAMES TO THE $LIBS VARIABLE
301 The ParseConfig() method now adds library file names returned
302 by the specified *-config command to the $LIBS construction
303 variable, instead of returning them (the same way it handles
306 -- ParseConfig() METHOD DOESN'T ADD DUPLICATES TO CONSTRUCTION VARIABLES
308 By default, the ParseConfig() method now avoids adding duplicate
309 entries to construction variables. The old behavior may be
310 specified using a new "unique=0" keyword argument.
312 -- WINDOWS %TEMP% and %TMP% VARIABLES ARE PROPAGATED AUTOMATICALLY
314 The %TEMP% and %TMP% external environment variables are now
315 propagated automatically to the command execution environment on
318 -- OUTPUT OF Configure() SUBSYSTEM CHANGED SLIGHTLY
320 The Configure() subsystem now reports tests results as "yes" and
321 "no" instead of "ok" and "failed." This might interfere with any
322 scripts that automatically parse the Configure() output from SCons.
324 -- VISUAL STUDIO ATL AND MFC DIRECTORIES NOT ADDED BY DEFAULT
326 When compiling with Microsoft Visual Studio, SCons no longer
327 adds the ATL and MFC directories to the INCLUDE and LIB
328 environment variables by default. If you want these directories
329 included in your environment variables, you should now set the
330 $MSVS_USE_MFC_DIRS *construction* variable when initializing
333 env = Environment(MSVS_USE_MFC_DIRS = 1)
335 -- DEPRECATED GLOBAL FUNCTIONS HAVE BEEN REMOVED
337 The following deprecated global functions have been removed:
338 ParseConfig(), SetBuildSignatureType(), SetContentSignatureType(),
339 SetJobs() and GetJobs().
341 -- DEPRECATED "validater" KEYWORD HAS BEEN REMOVED
343 The deprecated "validater" keyword to the Options.Add() method
346 Please note the following important changes since release 0.95:
348 -- BUILDERS NOW ALWAYS RETURN A LIST OF TARGETS
350 All Builder calls (both built-in like Program(), Library(),
351 etc. and customer Builders) now always return a list of target
352 Nodes. If the Builder only builds one target, the Builder
353 call will now return a list containing that target Node, not
354 the target Node itself as it used to do.
356 This change should be invisibile to most normal uses of the
357 return values from Builder calls. It will cause an error if the
358 SConscript file was performing some direct manipulation of the
359 returned Node value. For example, an attempt to print the name
360 of a target returned by the Object() Builder:
362 target = Object('foo.c')
366 Will now need to access the first element in the list returned by
369 target = Object('foo.c')
373 This change was introduced to make the data type returned by Builder
374 calls consistent (always a list), regardless of platform or number
377 -- DEFAULT SConsignFile() DATABASE SCHEME HAS CHANGED
379 The SConsignFile() function now uses an internally-supplied
380 SCons.dblite module as the default DB scheme for the .sconsign file.
381 If you are using the SConsignFile() function without an explicitly
382 specified dbm_module argument, this will cause all of your targets
383 to be recompiled the first time you use SCons 0.96. To preserve the
384 previous behavior, specify the "anydbm" module explicitly:
387 SConsignFile('.sconsign_file_name', anydbm)
389 -- INTERNAL .sconsign FILE FORMAT HAS CHANGED
391 The internal format of .sconsign files has been changed. This might
392 cause warnings about "ignoring corrupt .sconsign files" and rebuilds
393 when you use SCons 0.96 for the first time in a tree that was
394 previously built with SCons 0.95 or earlier.
396 -- INTERFACE CHANGE OF scan_check FUNCTION TO CUSTOM SCANNERS
398 The scan_check function that can be supplied to a custom Scanner now
399 must take two arguments, the Node to be checked and a construction
400 environment. It previously only used the Node as an argument.
402 -- DEFAULT SCANNERS NO LONGER HEED INTERNAL Scanner.add_skey() METHOD
404 The internal Scanner.add_skey() method no longer works for the
405 default scanners, which now use construction variables to hold their
406 lists of suffixes. If you had a custom Tool specification that was
407 reaching into the internals in this way to add a suffix to one of
408 the following scanner, you must now add the suffix to a construction
409 environment through which you plan to call the scanner, as follows:
411 CScan.add_skey('.x') => env.Append(CPPSUFFIXES = ['.x'])
412 DScan.add_skey('.x') => env.Append(DSUFFIXES = ['.x'])
413 FortranScan.add_skey('.x') => env.Append(FORTRANSUFFIXES = ['.x'])
415 -- KEYWORD ARGUMENTS TO Builder() HAVE BEEN REMOVED
417 The "node_factory" and "scanner" keyword arguments to the Builder()
418 function have been removed. In their place, the separate and more
419 flexible "target_factory," "source_factory," "target_scanner" and
420 "source scanner" keywords should be used instead.
422 -- ALL-DIGIT FILE "EXTENSIONS" ARE NOW PART OF THE FILE BASENAME
424 SCons now treats file "extensions" that contain all digits (for
425 example, "file.123") as part of the file basename, for easier
426 handling of version numbers in the names of shared libraries
427 and other files. Builders will now add their file extensions to
428 file names specified with all-digit extensions. If you need to
429 generate a file with an all-digit extension using a Builder that
430 adds a file extension, you can preserve the previous behavior by
431 wrapping the file name in a File() call.
433 -- Append()/Prepend() METHODS CHANGED WHEN USING UserList OBJECTS
435 The behavior of the env.Append() and env.Prepend() methods has
436 changed when appending a string value to a UserList, or vice versa.
437 They now behave like normal Python addition of a string to
438 a UserList. Given an initialization and an env.Append() call like:
440 env = Environment(VAR1=UserList(['foo']), VAR2='foo')
441 env.Append(VAR1='bar', VAR2=UserList(['bar'])
443 The resulting values of $VAR1 and $VAR2 will now be ['foo', 'b',
444 'a', 'r'] and ['f', 'o', 'o', 'bar'], respectively. This is because
445 Python UserList objects treat strings as sequences of letters when
446 adding them to the value of the UserList.
448 The old behavior of yielding $VAR1 and $VAR2 values of ['foo',
449 'bar'] when either variable is a UserList object now requires that
450 the string variables be enclosed in a list:
452 env = Environment(VAR1=UserList(['foo']), VAR2=['foo'])
453 env.Append(VAR1='bar', VAR2=UserList(['bar']))
455 Note that the SCons behavior when appending to normal lists has
456 *not* changed, and the behavior of all of the default values that
457 SCons uses to initialize all construction variables has *not*
458 changed. This change *only* affects any cases where you explicitly
459 use UserList objects to initialize or append to a variable.
461 Please note the following planned, future changes:
463 -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
465 Several internal variable names in SCons.Defaults for various
466 pre-made default Scanner objects have been deprecated and will
467 be removed in a future revision. In their place are several new
468 global variable names that are now part of the publicly-supported
471 NEW NAME DEPRECATED NAME
472 -------- ----------------------------
473 CScanner SCons.Defaults.CScan
474 DSCanner SCons.Defaults.DScan
475 SourceFileScanner SCons.Defaults.ObjSourceScan
476 ProgramScanner SCons.Defaults.ProgScan
478 Of these, only ObjSourceScan was probably used at all, to add
479 new mappings of file suffixes to other scanners for use by the
480 Object() Builder. This should now be done as follows:
482 SourceFileScanner.add_scanner('.x', XScanner)
484 -- THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY
486 The env.Copy() method (to make a copy of a construction
487 environment) is being replaced by the env.Clone() method.
489 In some future release, a deprecation warning will be added
490 to current uses of the env.Copy() method. At some point after
491 the deprecation warning, the env.Copy() method will either be
492 removed entirely or have its behavior changed.
494 You can prepare for this by changing all your uses of env.Copy()
495 to env.Clone(), which has the exact same calling arguments.
497 NOTE: CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE YOUR
498 SConscript FILES NOT WORK ON EARLIER VERSIONS OF SCons.
500 If you change SConscript files in software that you make available
501 for download or otherwise distribute, other users may try to
502 build your software with an earlier version of SCons that does
503 not have the env.Clone() method. We recommend preparing for
504 this in one of two ways:
506 -- Make your SConscript files backwards-compatible by
507 including the following code near the beginning of your
508 top-level SConstruct file:
510 import SCons.Environment
512 SCons.Environment.Environment.Clone
513 except AttributeError:
514 SCons.Environment.Environment.Clone = \
515 SCons.Environment.Environment.Copy
517 -- Use the EnsureSConsVersion() function to provide a
518 descriptive error message if your SConscript files
519 are executed by an earlier version of SCons:
521 EnsureSConsVersion(0, 96, 93)
523 SCons is developed with an extensive regression test suite, and a
524 rigorous development methodology for continually improving that suite.
525 Because of this, SCons is of sufficient quality that you can use it
526 for real work. The "beta" status of the release reflects that we
527 still may change interfaces in future releases, which may require
528 modifications to your SConscript files. We strive to hold these
529 changes to a minimum.
531 Nevertheless, please heed the following disclaimers:
533 - Please report any bugs or other problems that you find to our bug
534 tracker at our SourceForge project page:
536 http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
538 We have a reliable bug-fixing methodology already in place and
539 strive to respond to problems relatively quickly.
541 - Documentation is spottier than we'd like. You may need to dive
542 into the source code to figure out how to do something. Asking
543 questions on the scons-users mailing list is also welcome. We
544 will be addressing the documentation in upcoming releases, but
545 would be more than glad to have your assistance in correcting this
548 In particular, the "SCons Design" documentation on the SCons web
549 site is currently out of date, as we made significant changes to
550 portions of the interface as we figured out what worked and what
551 didn't during implementation.
553 - There may be performance issues. Improving SCons performance
554 is an ongoing priority. If you still find the performance
555 unacceptable, we would very much like to hear from you and learn
556 more about your configuration so we can optimize the right things.
558 - Error messages don't always exist where they'd be helpful.
559 Please let us know about any errors you ran into that would
560 have benefitted from a (more) descriptive message.
562 KNOWN PROBLEMS IN THIS RELEASE:
564 For a complete list of known problems, consult the SCons bug tracker
567 http://sourceforge.net/tracker/?atid=398971&group_id=30337&func=browse
569 - Support for parallel builds (-j) does not work on WIN32 systems
570 prior to *official* Python release 2.2 (not 2.2 pre-releases).
572 Prior to Python 2.2, there is a bug in Python's Win32
573 implementation such that when a thread spawns an external command,
574 it blocks all threads from running. This breaks the SCons
575 multithreading architecture used to support -j builds.
577 We have included a patch file, os_spawnv_fix.diff, that you can
578 use if you you want to fix your version of Python to support
579 parallel builds in SCons.
581 - Again, the "SCons Design" documentation on the SCons web
582 site is currently out of date. Take what you read there with a
585 - On Win32 systems, you must put a space between the redirection
586 characters < and >, and the specified files (or construction
587 variable expansions):
589 command < $SOURCE > $TARGET
591 If you don't supply a space (for example, "<$SOURCE"), SCons will
592 not recognize the redirection.
594 - MSVC .res files are not rebuilt when icons change.
596 - The -c option does not clean up .sconsign files or directories
597 created as part of the build, and also does not clean up
598 SideEffect files (for example, Visual Studio .pdb files).
600 - Switching content signatures from "MD5" to "timestamp" and back
601 again can cause unusual errors. These errors can be cleared up by
602 removing all .sconsign files.
604 - When using multiple Repositories, changing the name of an include
605 file can cause an old version of the file to be used.
607 - There is currently no way to force use of a relative path (../*)
608 for directories outside the top-level SConstruct file.
610 - The Jar() Builder will, on its second or subsequent invocation,
611 package up the .sconsign files that SCons uses to track signatures.
612 You can work around this by using the SConsignFile() function
613 to collect all of the .sconsign information into a single file
614 outside of the directory being packaged by Jar().
616 - SCons does not currently have a way to detect that an intermediate
617 file has been corrupted from outside and should be rebuilt.
619 - Unicode characters in path names do not work in all circumstances.
621 - A stray source file in a BuildDir can prevent targets from being
622 (re)built when they should.
624 - SCons does not automatically rebuild LaTeX files when the file
625 has an undefined reference on the first build.
627 - Use of --implicit-cache with TargetSignatures('content') can,
628 for some changes, not rebuild a file when necessary.
630 - SCons does not currently automatically check out SConstruct or
631 SConscript files from SCCS, RCS or BitKeeper.
633 - No support yet for the following planned command-line options:
635 -d -e -l --list-actions --list-derived --list-where
636 -o --override -p -r -R -w --write-filenames
637 -W --warn-undefined-variables
641 Thank you for your interest, and please let us know how we can help
642 improve SCons for your needs.
645 knight at baldmt dot com
646 http://www.baldmt.com/~knight/
648 With plenty of help from the SCons Development team: