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 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:
31 -- DIRECTORY TREES ARE NO LONGER AUTOMATICALLY SCANNED FOR CHANGES
33 Custom builders and Command() calls that accept directories as
34 source arguments no longer scan entire on-disk directory trees by
35 default. This means that their targets will not be automatically
36 rebuilt if a file changes on disk *unless* SCons already knows
37 about the file from a specific Builder or File() call. Note that
38 the targets will still be rebuilt correctly if a file changes
39 that SCons already knows about due to a Builder or other call.
41 The existing behavior of scanning on-disk directory trees for
42 any changed file can be maintained by passing the new DirScanner
43 global directory scanner as the source_scanner keyword argument
46 bld = Builder("build < $SOURCE > $TARGET",
47 source_scanner = DirScanner)
49 The same keyword argument can also be supplied to any Command()
50 calls that need to scan directory trees on-disk for changed files:
52 env.Command("archive.out", "directory",
53 "archiver -o $TARGET $SOURCE",
54 source_scanner = DirScanner)
56 This change was made because scanning directories by default
57 could cause huge slowdowns if a configurable directory like /usr
58 or /usr/local was passed as the source to a Builder or Command()
59 call, in which case SCons would scan the entire directory tree.
61 -- SIGNATURES ARE NOW STORED IN AN SConsignFile() BY DEFAULT,
62 CAUSING LIKELY REBUILDS; SPECIAL NOTE CONCERNING INTERACTION
65 The default behavior has been changed to store signature
66 information in a single .sconsign.dblite file in the top-level
67 SConstruct file. This will cause rebuilds on upgrade to 0.97,
68 unless you were already calling the SConsignFile() function in
69 your SConscript files.
71 The previous default behavior was to store signature information
72 in a .sconsign file in each directory that contained target
73 files that SCons knew about. The old behavior may be preserved
78 in any SConscript file.
80 If you are using the Repository feature, and are not already
81 using the SConsignFile() function in your build, you *must*
82 add "SConsignFile(None)" to your build configuration to keep
83 interoperating with an existing Repository that uses the old
84 behavior of a .sconsign file in each directory. Alternatively,
85 you can rebuild the Repository with the new default behavior.
87 -- OTHER SIGNATURE CHANGES WILL CAUSE LIKELY REBUILDS AFTER UPGRADE
89 This release adds several changes to the signature mechanism that
90 will cause SCons to rebuild most configurations after upgrading
91 (and when switching back to an earlier release from 0.97).
94 -- NORMALIZED PATHS IN SConsignFile() DATABASES ON WINDOWS
96 When using an SConsignFile() database, instead of individual
97 .sconsign files in each directory, the path names are
98 stored in normalized form with / (forward slash) separating
99 the elements. This may cause rebuilds on Windows systems
100 with hierarchical configurations.
102 -- STORED DEPENDENCY PATHS ARE NOW RELATIVE TO THE TARGET
104 SCons used to store the paths of all source files and
105 dependencies relative to the top-level SConstruct directory.
106 It now stores them relative to the directory of the
107 associated target file. This makes it possible to use
108 content signatures to subdivide a dependency tree without
109 causing unnecessary rebuilds due to an intermediate file in
110 one build being treated as a source file in a nother build.
112 This a step towards making it possible to write a hierarchy
113 of SConstruct files that allow developers to build just
114 one portion of a tree wherever there's an SConstruct file.
115 (Note that this would still require some specific code at
116 the top of each SConstruct file, but we hope to make this
117 an easier/more naturally supported thing in the future.)
119 -- PYTHON FUNCTION ACTION SIGNATURES HAVE CHANGED TO AVOID
120 FUTURE REBUILDS AND REBUILDS BETWEEN PYTHON VERSIONS
122 SCons Actions for Python functions use the functions byte
123 code to generate their signature. The byte code in older
124 versions of Python includes indications of the line numbers
125 at which the function's code appeared in its original
126 source file, which means that changes in the location of
127 an otherwise unmodified Python function would trigger
128 rebuilds. The line number byte codes are now removed
129 from the signature, which will cause any targets built by
130 Python function Actions (including various pre-supplied
131 SCons Actions) be rebuilt.
133 -- REMOVED CONVERSION FROM PRE-0.96 .sconsign FORMATS
135 Because this release involves so many other signature
136 changes that cause rebuilds, the support for automatically
137 converting signature information from .sconsign files
138 written by SCons versions prior to 0.96 has been removed.
140 -- ORDER OF -o FLAGS ON CERTAIN LINK COMMAND LINES HAS CHANGED
142 The -o flag that specifies an output file has been moved on
143 certain linker command lines to place it consistently after
144 the link command itself. This will cause recompilation
145 of target files created by these changed lines.
147 -- F95 AND F90 COMPILERS ARE NOW PREFERRED OVER F77
149 SCons now searches for Fortran 95 and Fortran 90 compilers first
150 in preference to Fortran 77. This may result in a different
151 Fortran compiler being used by default, although as Fortran 95 and
152 Fortran 90 are backwards compatible with Fortran 77, this should
153 not cause problems for standards-compliant Fortran programs.
154 On systems that have multiple versions of Fortran installed,
155 the Fortran 77 compiler may be explicitly selected by specifying
156 it when creating the construction environment:
158 env = Environment(tools = ['default', 'f77'])
160 -- /opt/bin AND /sw/bin ADDED TO DEFAULT EXECUTION PATH VARIABLES
162 On all POSIX systems, the default execution PATH variable has had
163 the /opt/bin directory added after the /usr/local/bin directory
164 and before /bin and /usr/bin directories. This may cause SCons
165 to find and/or different compilers, linkers, etc. if you have
166 any same-named utilities installed in /opt/bin that it previously
167 found in /bin or /usr/bin.
169 On Mac OS X (Darwin) systems, the /sw/bin directory has been added
170 to the end of the default execution PATH. This may cause SCons
171 to find compilers, linkers and other utilities it previously did
172 not, although it should not otherwise change existing behavior.
174 -- SOLARIS DEFAULT SHARED OBJECT PREFIXES AND SUFFIXES HAVE CHANGED
176 On Solaris, SCons now builds shared objects from C and C++ source
177 files with a default prefix of "so_" and a default suffix of ".o".
178 The previous default suffix of ".os" caused problems when trying
179 to use SCons with Sun WorkShop.
181 -- CACHED Configure() RESULTS ARE STORED IN A DIFFERENT FILE
183 The Configure() subsystem now stores its cached results in a
184 different file. This may cause configuration tests to be re-run
185 the first time after you install 0.97.
187 -- setup.py INSTALLS VERSION-NUMBERED SCRIPTS AND DIRS BY DEFAULT
189 The setup.py script has been changed to always install SCons in
190 a version-numbered directory (e.g. /usr/local/lib/scons-0.97
191 or D:\Python23\scons-0.97) and with a version-numbered script
192 name (scons-0.97) in addition to the usual installation of an
193 "scons" script name. A number of new setup.py options allow
194 control over what does or does not get installed, and where.
195 See the README.txt or README files for additional information.
197 -- setup.py NOW INSTALLS MAN PAGES ON UNIX AND Linux SYSTEMS
199 The SCons setup.py script now installs the "scons.1" and
200 "sconsign.1" man pages on UNIX and Linux systems. A
203 -- env.subst() NO LONGER EXPANDS $TARGET, $SOURCES, etc. BY DEFAULT
205 Calls to the env.subst() method to interpolate construction
206 variables in strings no longer automatically expand the special
207 variables $TARGET, $TARGETS, $SOURCE and $SOURCES. The keyword
208 variables "target" and "source" must now be set to the lists
209 of target and source files to be used in expansion of those
210 variables, when desired.
212 This is most likely necessary for any env.subst() calls within
213 a Python function being used as an SCons action for a Builder:
215 def build_it(env, target, source):
216 env.subst('$STRING', target=targets, source=sources)
217 MyBuilder = Builder(action=build_it)
219 The "target" and "source" keyword arguments are backwards
220 compatible and can be added to SConscript files without breaking
221 builds on systems using older SCons releases.
223 -- ParseConfig() METHOD ADDS LIBRARY FILE NAMES TO THE $LIBS VARIABLE
225 The ParseConfig() method now adds library file names returned
226 by the specified *-config command to the $LIBS construction
227 variable, instead of returning them (the same way it handles
230 -- ParseConfig() METHOD DOESN'T ADD DUPLICATES TO CONSTRUCTION VARIABLES
232 By default, the ParseConfig() method now avoids adding duplicate
233 entries to construction variables. The old behavior may be
234 specified using a new "unique=0" keyword argument.
236 -- WINDOWS %TEMP% and %TMP% VARIABLES ARE PROPAGATED AUTOMATICALLY
238 The %TEMP% and %TMP% external environment variables are now
239 propagated automatically to the command execution environment on
242 -- VISUAL STUDIO ATL AND MFC DIRECTORIES NOT ADDED BY DEFAULT
244 When compiling with Microsoft Visual Studio, SCons no longer
245 adds the ATL and MFC directories to the INCLUDE and LIB
246 environment variables by default. If you want these directories
247 included in your environment variables, you should now set the
248 $MSVS_USE_MFC_DIRS *construction* variable when initializing
251 env = Environment(MSVS_USE_MFC_DIRS = 1)
253 -- BUILDERS RETURN A LIST-LIKE OBJECT, NOT A REGULAR LIST
255 Builder calls now return an object that behaves like a list
256 (and which provides some other functionality), not an underlying
257 Python list. In general, this should not cause any problems,
258 although it introduces a subtle change in the following behavior:
260 obj += env.Object('foo.c')
262 If "obj" is a regular Python list, Python will no longer update
263 the "obj" in place, because the return value from env.Object()
264 is no longer the same type. Python will instead allocate a
265 new object and assign the local variable "obj" to it. If "obj"
266 is defined in an SConscript file that calls another SConscript
267 file containing the above code, "obj" in the first SConscript
268 file will not contain the object file nodes created by the
271 You can guarantee that a list will be updated in place regardless
272 of which SConscript file defines it and which adds to it by
273 using the list append() method as follows:
275 obj.append(env.Object('foo.c'))
277 -- OUTPUT OF Configure() SUBSYSTEM CHANGED SLIGHTLY
279 The Configure() subsystem now reports tests results as "yes" and
280 "no" instead of "ok" and "failed." This might interfere with any
281 scripts that automatically parse the Configure() output from SCons.
283 -- DEPRECATED GLOBAL FUNCTIONS HAVE BEEN REMOVED
285 The following deprecated global functions have been removed:
286 ParseConfig(), SetBuildSignatureType(), SetContentSignatureType(),
287 SetJobs() and GetJobs().
289 -- DEPRECATED "validater" KEYWORD HAS BEEN REMOVED
291 The deprecated "validater" keyword to the Options.Add() method
294 -- INTERNAL FUNCTIONS AND CLASSES HAVE MOVED FROM SCons.Util
296 All internal functions and classes related to string substitution
297 have been moved out of the SCons.Util module into their own
298 SCons.Subst module. The following classes have been moved:
306 And the following functions have moved:
315 If your SConscript files have been using any of these function
316 directly from the SCons.Util module (which they ultimately should
317 not be!), you will need to modify them.
319 Please note the following important changes since release 0.95:
321 -- BUILDERS NOW ALWAYS RETURN A LIST OF TARGETS
323 All Builder calls (both built-in like Program(), Library(),
324 etc. and customer Builders) now always return a list of target
325 Nodes. If the Builder only builds one target, the Builder
326 call will now return a list containing that target Node, not
327 the target Node itself as it used to do.
329 This change should be invisibile to most normal uses of the
330 return values from Builder calls. It will cause an error if the
331 SConscript file was performing some direct manipulation of the
332 returned Node value. For example, an attempt to print the name
333 of a target returned by the Object() Builder:
335 target = Object('foo.c')
339 Will now need to access the first element in the list returned by
342 target = Object('foo.c')
346 This change was introduced to make the data type returned by Builder
347 calls consistent (always a list), regardless of platform or number
350 -- DEFAULT SConsignFile() DATABASE SCHEME HAS CHANGED
352 The SConsignFile() function now uses an internally-supplied
353 SCons.dblite module as the default DB scheme for the .sconsign file.
354 If you are using the SConsignFile() function without an explicitly
355 specified dbm_module argument, this will cause all of your targets
356 to be recompiled the first time you use SCons 0.96. To preserve the
357 previous behavior, specify the "anydbm" module explicitly:
360 SConsignFile('.sconsign_file_name', anydbm)
362 -- INTERNAL .sconsign FILE FORMAT HAS CHANGED
364 The internal format of .sconsign files has been changed. This might
365 cause warnings about "ignoring corrupt .sconsign files" and rebuilds
366 when you use SCons 0.96 for the first time in a tree that was
367 previously built with SCons 0.95 or earlier.
369 -- INTERFACE CHANGE OF scan_check FUNCTION TO CUSTOM SCANNERS
371 The scan_check function that can be supplied to a custom Scanner now
372 must take two arguments, the Node to be checked and a construction
373 environment. It previously only used the Node as an argument.
375 -- DEFAULT SCANNERS NO LONGER HEED INTERNAL Scanner.add_skey() METHOD
377 The internal Scanner.add_skey() method no longer works for the
378 default scanners, which now use construction variables to hold their
379 lists of suffixes. If you had a custom Tool specification that was
380 reaching into the internals in this way to add a suffix to one of
381 the following scanner, you must now add the suffix to a construction
382 environment through which you plan to call the scanner, as follows:
384 CScan.add_skey('.x') => env.Append(CPPSUFFIXES = ['.x'])
385 DScan.add_skey('.x') => env.Append(DSUFFIXES = ['.x'])
386 FortranScan.add_skey('.x') => env.Append(FORTRANSUFFIXES = ['.x'])
388 -- KEYWORD ARGUMENTS TO Builder() HAVE BEEN REMOVED
390 The "node_factory" and "scanner" keyword arguments to the Builder()
391 function have been removed. In their place, the separate and more
392 flexible "target_factory," "source_factory," "target_scanner" and
393 "source scanner" keywords should be used instead.
395 -- ALL-DIGIT FILE "EXTENSIONS" ARE NOW PART OF THE FILE BASENAME
397 SCons now treats file "extensions" that contain all digits (for
398 example, "file.123") as part of the file basename, for easier
399 handling of version numbers in the names of shared libraries
400 and other files. Builders will now add their file extensions to
401 file names specified with all-digit extensions. If you need to
402 generate a file with an all-digit extension using a Builder that
403 adds a file extension, you can preserve the previous behavior by
404 wrapping the file name in a File() call.
406 -- Append()/Prepend() METHODS CHANGED WHEN USING UserList OBJECTS
408 The behavior of the env.Append() and env.Prepend() methods has
409 changed when appending a string value to a UserList, or vice versa.
410 They now behave like normal Python addition of a string to
411 a UserList. Given an initialization and an env.Append() call like:
413 env = Environment(VAR1=UserList(['foo']), VAR2='foo')
414 env.Append(VAR1='bar', VAR2=UserList(['bar'])
416 The resulting values of $VAR1 and $VAR2 will now be ['foo', 'b',
417 'a', 'r'] and ['f', 'o', 'o', 'bar'], respectively. This is because
418 Python UserList objects treat strings as sequences of letters when
419 adding them to the value of the UserList.
421 The old behavior of yielding $VAR1 and $VAR2 values of ['foo',
422 'bar'] when either variable is a UserList object now requires that
423 the string variables be enclosed in a list:
425 env = Environment(VAR1=UserList(['foo']), VAR2=['foo'])
426 env.Append(VAR1='bar', VAR2=UserList(['bar']))
428 Note that the SCons behavior when appending to normal lists has
429 *not* changed, and the behavior of all of the default values that
430 SCons uses to initialize all construction variables has *not*
431 changed. This change *only* affects any cases where you explicitly
432 use UserList objects to initialize or append to a variable.
434 Please note the following planned, future changes:
436 -- SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED
438 Several internal variable names in SCons.Defaults for various
439 pre-made default Scanner objects have been deprecated and will
440 be removed in a future revision. In their place are several new
441 global variable names that are now part of the publicly-supported
444 NEW NAME DEPRECATED NAME
445 -------- ----------------------------
446 CScanner SCons.Defaults.CScan
447 DSCanner SCons.Defaults.DScan
448 SourceFileScanner SCons.Defaults.ObjSourceScan
449 ProgramScanner SCons.Defaults.ProgScan
451 Of these, only ObjSourceScan was probably used at all, to add
452 new mappings of file suffixes to other scanners for use by the
453 Object() Builder. This should now be done as follows:
455 SourceFileScanner.add_scanner('.x', XScanner)
457 SCons is developed with an extensive regression test suite, and a
458 rigorous development methodology for continually improving that suite.
459 Because of this, SCons is of sufficient quality that you can use it
460 for real work. The "beta" status of the release reflects that we
461 still may change interfaces in future releases, which may require
462 modifications to your SConscript files. We strive to hold these
463 changes to a minimum.
465 Nevertheless, please heed the following disclaimers:
467 - Please report any bugs or other problems that you find to our bug
468 tracker at our SourceForge project page:
470 http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971
472 We have a reliable bug-fixing methodology already in place and
473 strive to respond to problems relatively quickly.
475 - Documentation is spottier than we'd like. You may need to dive
476 into the source code to figure out how to do something. Asking
477 questions on the scons-users mailing list is also welcome. We
478 will be addressing the documentation in upcoming releases, but
479 would be more than glad to have your assistance in correcting this
482 In particular, the "SCons Design" documentation on the SCons web
483 site is currently out of date, as we made significant changes to
484 portions of the interface as we figured out what worked and what
485 didn't during implementation.
487 - There may be performance issues. Improving SCons performance
488 is an ongoing priority. If you still find the performance
489 unacceptable, we would very much like to hear from you and learn
490 more about your configuration so we can optimize the right things.
492 - Error messages don't always exist where they'd be helpful.
493 Please let us know about any errors you ran into that would
494 have benefitted from a (more) descriptive message.
496 KNOWN PROBLEMS IN THIS RELEASE:
498 For a complete list of known problems, consult the SCons bug tracker
501 http://sourceforge.net/tracker/?atid=398971&group_id=30337&func=browse
503 - Support for parallel builds (-j) does not work on WIN32 systems
504 prior to *official* Python release 2.2 (not 2.2 pre-releases).
506 Prior to Python 2.2, there is a bug in Python's Win32
507 implementation such that when a thread spawns an external command,
508 it blocks all threads from running. This breaks the SCons
509 multithreading architecture used to support -j builds.
511 We have included a patch file, os_spawnv_fix.diff, that you can
512 use if you you want to fix your version of Python to support
513 parallel builds in SCons.
515 - Again, the "SCons Design" documentation on the SCons web
516 site is currently out of date. Take what you read there with a
519 - On Win32 systems, you must put a space between the redirection
520 characters < and >, and the specified files (or construction
521 variable expansions):
523 command < $SOURCE > $TARGET
525 If you don't supply a space (for example, "<$SOURCE"), SCons will
526 not recognize the redirection.
528 - MSVC .res files are not rebuilt when icons change.
530 - The -c option does not clean up .sconsign files or directories
531 created as part of the build, and also does not clean up
532 SideEffect files (for example, Visual Studio .pdb files).
534 - Switching content signatures from "MD5" to "timestamp" and back
535 again can cause unusual errors. These errors can be cleared up by
536 removing all .sconsign files.
538 - When using multiple Repositories, changing the name of an include
539 file can cause an old version of the file to be used.
541 - There is currently no way to force use of a relative path (../*)
542 for directories outside the top-level SConstruct file.
544 - The Jar() Builder will, on its second or subsequent invocation,
545 package up the .sconsign files that SCons uses to track signatures.
546 You can work around this by using the SConsignFile() function
547 to collect all of the .sconsign information into a single file
548 outside of the directory being packaged by Jar().
550 - SCons does not currently have a way to detect that an intermediate
551 file has been corrupted from outside and should be rebuilt.
553 - Unicode characters in path names do not work in all circumstances.
555 - A stray source file in a BuildDir can prevent targets from being
556 (re)built when they should.
558 - SCons does not automatically rebuild LaTeX files when the file
559 has an undefined reference on the first build.
561 - Use of --implicit-cache with TargetSignatures('content') can,
562 for some changes, not rebuild a file when necessary.
564 - SCons does not currently automatically check out SConstruct or
565 SConscript files from SCCS, RCS or BitKeeper.
567 - No support yet for the following planned command-line options:
569 -d -e -l --list-actions --list-derived --list-where
570 -o --override -p -r -R -w --write-filenames
571 -W --warn-undefined-variables
575 Thank you for your interest, and please let us know how we can help
576 improve SCons for your needs.
579 knight at baldmt dot com
580 http://www.baldmt.com/~knight/
582 With plenty of help from the SCons Development team: