berlios / sconsexe / RELEASE.txt

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
# Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007 The SCons Foundation
# src/RELEASE.txt 2523 2007/12/12 09:37:41 knight


                 SCons - a software construction tool

                            Release Notes


This is a beta release of SCons, a tool for building software (and other
files).  SCons is implemented in Python, and its "configuration files"
are actually Python scripts, allowing you to use the full power of a
real scripting language to solve build problems.  You do not, however,
need to know Python to use SCons effectively.

So that everyone using SCons can help each other learn how to use it
more effectively, please sign up for the scons-users mailing list at:

    http://lists.sourceforge.net/lists/listinfo/scons-users



RELEASE 0.97.0d20071212 - Wed, 12 Dec 2007 09:29:32 -0600

  This is the eighth beta release of SCons.  Please consult the
  CHANGES.txt file for a list of specific changes since last release.

  Please note the following important changes since release 0.97.0d20070918:

    --  SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS
        ON OPEN FILE HANDLES TO CREATED PROCESSES

        On Windows systems, SCons now redefines the Python open()
        and file() functions so that, if the Python Win32 extensions
        are available, the file handles for any opened files will *not*
        be inherited by subprocesses, such as the spawned compilers and
        other tools invoked to build the software.

        This prevents certain race conditions where a file handle for
        a file opened by Python (either in a Python function action,
        or directly in a SConscript file) could be inherited and help
        open by a subprocess, interfering with the ability of other
        processes to create or modify the file.

        In general, this should not cause problems for the vast majority
        of configurations.  The only time this would be a problem would be
        in the unlikely event that a process spawned by SCons specifically
        *expected* to use an inherited file handle opened by SCons.

        If the Python Win32 extensions are not installed or are an
        earlier version that does not have the ability to disable file
        handle inheritance, SCons will print a warning message when the
        -j option is used.  The warning message may be suppressed by
        specifying --warn=no-parallel-support.

  Please note the following important changes since release 0.97.0d20070809:

    --  "content" SIGNATURES ARE NOW THE DEFAULT BEHAVIOR

        The default behavior of SCons is now to use the MD5 checksum of
        all file contents to decide if any files have changed and should
        cause rebuilds of their source files.  This means that SCons may
        decide not to rebuild "downstream" targets if a a given input
        file is rebuilt to the exact same contents as the last time.
        The old behavior may preserved by explicity specifying:

            TargetSignatures("build")

        In any of your SConscript files.

    --  TARGETS NOW IMPLICITLY DEPEND ON THE COMMAND THAT BUILDS THEM

        For all targets built by calling external commands (such as a
        compiler or other utility), SCons now adds an implicit dependency
        on the command(s) used to build the target.

        This will cause rebuilds of all targets built by external commands
        when running SCons in a tree built by previous version of SCons,
        in order to update the recorded signatures.

        The old behavior of not having targets depend on the external
        commands that build them can be preserved by setting a new
        $IMPLICIT_COMMAND_DEPENDENCIES construction variable to a
        non-True value:

            env = Environment(IMPLICIT_COMMAND_DEPENDENCIES = 0)
        
        or by adding Ignore() calls for any targets where the behavior
        is desired:

            Ignore('/usr/bin/gcc', 'foo.o')

        Both of these settings are compatible with older versions
        of SCons.

    --  CHANGING SourceSignature() MAY CAUSE "UNECESSARY" REBUILDS

        If you change the SourceSignature() value from 'timestamp' to
        'MD5', SCons will now rebuild targets that were already up-to-date
        with respect to their source files.

        This will happen because SCons did not record the content
        signatures of the input source files when the target was last
        built--it only recorded the timestamps--and it must record them
        to make sure the signature information is correct.  However,
        the content of source files may have changed since the last
        timestamp build was performed, and SCons would not have any way to
        verify that.  (It would have had to open up the file and record
        a content signature, which is one of the things you're trying to
        avoid by specifying use of timestamps....)  So in order to make
        sure the built targets reflect the contents of the source files,
        the targets must be rebuilt.

        Change the SourceSignature() value from 'MD5' to 'timestamp'
        should correctly not rebuild target files, because the timestamp
        of the files is always recorded.

        In previous versions of SCons, changing the SourceSignature()
        value would lead to unpredictable behavior, usually including
        rebuilding targets.

    --  THE Return() FUNCTION NOW ACTUALLY RETURNS IMMEDIATELY

        The Return() function now immediately stops processing the
        SConscript file in which it appears and returns the values of the
        variables named in its arguments.  It used to continue processing
        the rest of the SConscript file, and then return the values of the
        specified variables at the point the Return() function was called.

        The old behavior may be requested by adding a "stop=False"
        keyword argument to the Return() call:

                Return('value', stop=False)

        The "stop=" keyword argument is *not* compatible with SCons
        versions 0.97.0d20070809 or earlier.

  Please note the following important changes since release 0.97:

    --  env.CacheDir() NOW ONLY AFFECTS CONSTRUCTION ENVIRONMENT TARGETS

        The env.CacheDir() method now only causes derived files to be
        retrieved from the specified cache directory for targets built
        with the specified specified construction environment ("env").

        Previously, any call to env.CacheDir() or CacheDir() would modify
        a global setting and cause all built targets to be retrieved
        from the specified cache directory.  This behavior was changed so
        that env.CacheDir() would be consistent with other construction
        environment methods, which only affect targets built with the
        specified construction environment.

        The old behavior of changing the global behavior may be preserved
        by changing any env.CacheDir() calls to:

                CacheDir('/path/to/cache/directory')

        The above change is backwards-compatible and works in all earlier
        versions of SCons that support CacheDir().

    --  INTERPRETATION OF SUFFIX-LESS SOURCE ARGUMENTS HAS CHANGED

        The interpretation of source arguments (files) without suffixes
        has changed in one specific configuration.

        Previously, if a Builder had a src_suffix specified (indicating
        that source files without suffixes should have that suffix
        appended), the suffix would only be applied to suffix-less source
        arguments if the Builder did *not* have one or more attached
        source Builders (that is, the Builder was not a "multi-stage"
        Builder).  So in the following configuration:

                build_foo = Builder(src_suffix = '.foo')
                build_bar = Builder(src_suffix = '.bar',
                                    src_builder = build_bar)

                env = Environment(BUILDERS = {
                                   'Foo' : build_foo,
                                   'Boo' : build_bar,
                                  })

                env.Foo('tgt1', 'src1')
                env.Bar('tgt2', 'src2')
        
        SCons would have expected to find a source file 'src1.foo' for the
        env.Foo() call, but a source file 'src2' for the env.Bar() call.

        This behavior has now been made consistent, so that the two
        above calls would expect source files named 'src1.foo' and
        'src2.bar', respectively.

        Note that, if genuinely desired, the old behavior of building
        from a source file without a suffix at all (when the Builder has
        a src_suffix *and* a src_builder) can be specified explicity by
        turning the string into a File Node directly:

                env.Bar('tgt2', File('src2'))

        The above use of File() is backwards-compatible and will work
        on earlier versions of SCons.

    --  THE DEFAULT EXECUTION PATH FOR Solaris HAS CHANGED

        On Solaris systems, SCons now adds the "/opt/SUNWspro/bin"
        directory to the default execution $PATH variable before the
        "/usr/ccs/bin" directory.  This was done to reflect the fact
        that /opt/SUNWspro/ is the default for SUN tools, but it may
        cause a different compiler to be used if you have compilers
        installed in both directories.

    --  GENERATED config.h FILES NOW SAY "#define HAVE_{FEATURE} 1"

        When generating a "config.h" file, SCons now defines values that
        record the existence of a feature with a "1" value:

            #define HAVE_FEATURE 1

        Instead of printing the line without a "1", as it used to:

            #define HAVE_FEATURE

        This should not cause any problems in the normal use of "#ifdef
        HAVE_{FEATURE}" statements interpreted by a C preprocessor, but
        might cause a compatibility issue if a script or other utility
        looks for an exact match of the previous text.

  Please note the following important changes since release 0.96.93:

    --  THE --debug=memoizer OPTION NOW REQUIRES PYTHON 2.2 OR LATER

        The --debug=memoizer option now prints a warning message and
        does nothing if SCons is run on a version of Python that does
        not support metaclasses (earlier than Python 2.2).

    --  THE --debug=nomemoizer OPTION DOES NOTHING AND IS NOW DEPRECATED

        The --debug=nomemoizer no longer does anything and instead
        now generates a warning message about being deprecated.  The
        --debug=nomemoizer will be removed completely in a future release.

  Please note the following important changes since release 0.96.91:

    --  /opt/bin AND /sw/bin ADDED TO DEFAULT EXECUTION PATH VARIABLES

        On all POSIX systems, the default execution PATH variable has had
        the /opt/bin directory added after the /usr/local/bin directory
        and before /bin and /usr/bin directories.  This may cause SCons
        to find and/or use different compilers, linkers, etc., if you
        have any same-named utilities installed in /opt/bin that SCons
        previously found in /bin or /usr/bin.

        On Mac OS X (Darwin) systems, the /sw/bin directory has been added
        to the end of the default execution PATH.  This may cause SCons
        to find compilers, linkers and other utilities it previously did
        not, although it should not otherwise change existing behavior.

    --  Configure.Checklib() ARGUMENTS HAVE CHANGED TO MATCH DOCUMENTATION

        The order of the arguments to the Configure.CheckLib() function
        has changed to put the "autoadd" keyword argument last, matching
        the documentation in the man page.  This could cause problems
        for any calls to Configure.Checklib() that were relying on the
        order of the arguments.  Specifying all arguments as keyword
        arguments will work on both older and newer versions of SCons.

    --  env.subst() NO LONGER EXPANDS $TARGET, $SOURCES, etc. BY DEFAULT

        Calls to the env.subst() method to interpolate construction
        variables in strings no longer automatically expand the special
        variables $TARGET, $TARGETS, $SOURCE and $SOURCES.  The keyword
        variables "target" and "source" must now be set to the lists
        of target and source files to be used in expansion of those
        variables, when desired.

        This is most likely necessary for any env.subst() calls within
        a Python function being used as an SCons action for a Builder:

            def build_it(env, target, source):
                env.subst('$STRING', target=targets, source=sources)
            MyBuilder = Builder(action=build_it)

        The "target" and "source" keyword arguments are backwards
        compatible and can be added to SConscript files without breaking
        builds on systems using older SCons releases.

    --  INTERNAL FUNCTIONS AND CLASSES HAVE MOVED FROM SCons.Util

        All internal functions and classes related to string substitution
        have been moved out of the SCons.Util module into their own
        SCons.Subst module.  The following classes have been moved:

                Literal
                SpecialAttrWrapper
                NLWrapper
                Targets_or_Sources
                Target_or_Source

        And the following functions have moved:

                quote_spaces()
                escape_list()
                subst_dict()
                scons_subst()
                scons_subst_list()
                scons_subst_once()

        If your SConscript files have been using any of these function
        directly from the SCons.Util module (which they ultimately should
        not be!), you will need to modify them.

  Please note the following important changes since release 0.96.90:

    --  SIGNATURES ARE NOW STORED IN AN SConsignFile() BY DEFAULT,
        CAUSING LIKELY REBUILDS; SPECIAL NOTE CONCERNING INTERACTION
        WITH REPOSITORIES

        The default behavior has been changed to store signature
        information in a single .sconsign.dblite file in the top-level
        SConstruct file.  This will cause rebuilds on upgrade to 0.97,
        unless you were already calling the SConsignFile() function in
        your SConscript files.

        The previous default behavior was to store signature information
        in a .sconsign file in each directory that contained target
        files that SCons knew about.  The old behavior may be preserved
        by specifying:

              SConsignFile(None)

        in any SConscript file.

        If you are using the Repository feature, and are not already
        using the SConsignFile() function in your build, you *must*
        add "SConsignFile(None)" to your build configuration to keep
        interoperating with an existing Repository that uses the old
        behavior of a .sconsign file in each directory.  Alternatively,
        you can rebuild the Repository with the new default behavior.

    --  OTHER SIGNATURE CHANGES WILL CAUSE LIKELY REBUILDS AFTER UPGRADE

        This release adds several changes to the signature mechanism that
        will cause SCons to rebuild most configurations after upgrading
        (and when switching back to an earlier release from 0.97).
        These changes are:

          --  NORMALIZED PATHS IN SConsignFile() DATABASES ON WINDOWS

              When using an SConsignFile() database, instead of
              individual .sconsign files in each directory, the path
              names are stored in normalized form with / (forward slash)
              separating the elements.  This may cause rebuilds when
              upgrading to SCons 0.97 on Windows systems with hierarchical
              build configurations.

          --  STORED DEPENDENCY PATHS ARE NOW RELATIVE TO THE TARGET

              SCons used to store the paths of all source files and
              dependencies relative to the top-level SConstruct directory.
              It now stores them relative to the directory of the
              associated target file.  This makes it possible to use
              content signatures to subdivide a dependency tree without
              causing unnecessary rebuilds due to an intermediate file in
              one build being treated as a source file in a nother build.

              This is a step towards making it possible to write a
              hierarchy of SConstruct files that allow developers
              to build just one portion of a tree wherever there's an
              SConstruct file.  (Note that this would still require some
              specific code at the top of each SConstruct file, but we
              hope to make this an easier/more naturally supported thing
              in the future.)

          --  PYTHON FUNCTION ACTION SIGNATURES HAVE CHANGED TO AVOID
              FUTURE REBUILDS AND REBUILDS BETWEEN PYTHON VERSIONS

              SCons Actions for Python functions use the function's
              byte code to generate their signature.  The byte code
              in older versions of Python includes indications of the
              line numbers at which the function's code appeared in
              its original source file, which means that changes in the
              location of an otherwise unmodified Python function would
              trigger rebuilds.  The line number byte codes are now
              removed from the signature, which will cause any targets
              built by Python function Actions (including various
              pre-supplied SCons Actions) to be rebuilt.

          --  REMOVED CONVERSION FROM PRE-0.96 .sconsign FORMATS

              Because this release involves so many other signature
              changes that cause rebuilds, the support for automatically
              converting signature information from .sconsign files
              written by SCons versions prior to 0.96 has been removed.

          --  ORDER OF -o FLAGS ON CERTAIN LINK COMMAND LINES HAS CHANGED

              The -o flag that specifies an output file has been moved
              on certain linker command lines to place it consistently
              right after the link command itself.  This will cause
              recompilation of target files created by these changed
              lines.

    --  F95 AND F90 COMPILERS ARE NOW PREFERRED OVER F77

        SCons now searches for Fortran 95 and Fortran 90 compilers first
        in preference to Fortran 77.  This may result in a different
        Fortran compiler being used by default, although as Fortran 95 and
        Fortran 90 are backwards compatible with Fortran 77, this should
        not cause problems for standards-compliant Fortran programs.
        On systems that have multiple versions of Fortran installed,
        the Fortran 77 compiler may be explicitly selected by specifying
        it when creating the construction environment:

            env = Environment(tools = ['default', 'f77'])

    --  SOLARIS DEFAULT SHARED OBJECT PREFIXES AND SUFFIXES HAVE CHANGED

        On Solaris, SCons now builds shared objects from C and C++ source
        files with a default prefix of "so_" and a default suffix of ".o".
        The previous default suffix of ".os" caused problems when trying
        to use SCons with Sun WorkShop.

    --  CACHED Configure() RESULTS ARE STORED IN A DIFFERENT FILE

        The Configure() subsystem now stores its cached results in a
        different file.  This may cause configuration tests to be re-run
        the first time after you install 0.97.

    --  setup.py INSTALLS VERSION-NUMBERED SCRIPTS AND DIRS BY DEFAULT

        The setup.py script has been changed to always install SCons in
        a version-numbered directory (e.g. /usr/local/lib/scons-0.97
        or D:\Python23\scons-0.97) and with a version-numbered script
        name (scons-0.97) in addition to the usual installation of an
        "scons" script name.  A number of new setup.py options allow
        control over what does or does not get installed, and where.
        See the README.txt or README files for additional information.

    --  setup.py NOW INSTALLS MAN PAGES ON UNIX AND Linux SYSTEMS

        The SCons setup.py script now installs the "scons.1" and
        "sconsign.1" man pages on UNIX and Linux systems.  A
        new --no-install-man

    --  BUILDERS RETURN A LIST-LIKE OBJECT, NOT A REGULAR LIST

        Builder calls now return an object that behaves like a list
        (and which provides some other functionality), not an underlying
        Python list.  In general, this should not cause any problems,
        although it introduces a subtle change in the following behavior:

                obj += env.Object('foo.c')

        If "obj" is a regular Python list, Python will no longer update
        the "obj" in place, because the return value from env.Object()
        is no longer the same type.  Python will instead allocate a
        new object and assign the local variable "obj" to it.  If "obj"
        is defined in an SConscript file that calls another SConscript
        file containing the above code, "obj" in the first SConscript
        file will not contain the object file nodes created by the
        env.Object() call.

        You can guarantee that a list will be updated in place regardless
        of which SConscript file defines it and which adds to it by
        using the list extend() method as follows:

                obj.extend(env.Object('foo.c'))

  Please note the following important changes since release 0.96.1:

    --  DIRECTORY TREES ARE NO LONGER AUTOMATICALLY SCANNED FOR CHANGES

        Custom builders and Command() calls that accept directories as
        source arguments no longer scan entire on-disk directory trees by
        default.  This means that their targets will not be automatically
        rebuilt if a file changes on disk *unless* SCons already knows
        about the file from a specific Builder or File() call.  Note that
        the targets will still be rebuilt correctly if a file changes
        that SCons already knows about due to a Builder or other call.

        The existing behavior of scanning on-disk directory trees for
        any changed file can be maintained by passing the new DirScanner
        global directory scanner as the source_scanner keyword argument
        to the Builder call:

            bld = Builder("build < $SOURCE > $TARGET",
                          source_scanner = DirScanner)

        The same keyword argument can also be supplied to any Command()
        calls that need to scan directory trees on-disk for changed files:

            env.Command("archive.out", "directory",
                        "archiver -o $TARGET $SOURCE",
                        source_scanner = DirScanner)

        This change was made because scanning directories by default
        could cause huge slowdowns if a configurable directory like /usr
        or /usr/local was passed as the source to a Builder or Command()
        call, in which case SCons would scan the entire directory tree.

    --  ParseConfig() METHOD ADDS LIBRARY FILE NAMES TO THE $LIBS VARIABLE

        The ParseConfig() method now adds library file names returned
        by the specified *-config command to the $LIBS construction
        variable, instead of returning them (the same way it handles
        the -l option).

    --  ParseConfig() METHOD DOESN'T ADD DUPLICATES TO CONSTRUCTION VARIABLES

        By default, the ParseConfig() method now avoids adding duplicate
        entries to construction variables.  The old behavior may be
        specified using a new "unique=0" keyword argument.

    --  WINDOWS %TEMP% and %TMP% VARIABLES ARE PROPAGATED AUTOMATICALLY

        The %TEMP% and %TMP% external environment variables are now
        propagated automatically to the command execution environment on
        Windows systems.

    --  OUTPUT OF Configure() SUBSYSTEM CHANGED SLIGHTLY

        The Configure() subsystem now reports tests results as "yes" and
        "no" instead of "ok" and "failed."  This might interfere with any
        scripts that automatically parse the Configure() output from SCons.

    --  VISUAL STUDIO ATL AND MFC DIRECTORIES NOT ADDED BY DEFAULT

        When compiling with Microsoft Visual Studio, SCons no longer
        adds the ATL and MFC directories to the INCLUDE and LIB
        environment variables by default.  If you want these directories
        included in your environment variables, you should now set the
        $MSVS_USE_MFC_DIRS *construction* variable when initializing
        your environment:

            env = Environment(MSVS_USE_MFC_DIRS = 1)

    --  DEPRECATED GLOBAL FUNCTIONS HAVE BEEN REMOVED

        The following deprecated global functions have been removed:
        ParseConfig(), SetBuildSignatureType(), SetContentSignatureType(),
        SetJobs() and GetJobs().

    --  DEPRECATED "validater" KEYWORD HAS BEEN REMOVED

        The deprecated "validater" keyword to the Options.Add() method
        has been removed.

  Please note the following important changes since release 0.95:

    --  BUILDERS NOW ALWAYS RETURN A LIST OF TARGETS

        All Builder calls (both built-in like Program(), Library(),
        etc. and customer Builders) now always return a list of target
        Nodes.   If the Builder only builds one target, the Builder
        call will now return a list containing that target Node, not
        the target Node itself as it used to do.

        This change should be invisibile to most normal uses of the
        return values from Builder calls.  It will cause an error if the
        SConscript file was performing some direct manipulation of the
        returned Node value.  For example, an attempt to print the name
        of a target returned by the Object() Builder:

              target = Object('foo.c')
              # OLD WAY
              print target

        Will now need to access the first element in the list returned by
        the Object() call:

              target = Object('foo.c')
              # NEW WAY
              print target[0]

        This change was introduced to make the data type returned by Builder
        calls consistent (always a list), regardless of platform or number
        of returned targets.

    --  DEFAULT SConsignFile() DATABASE SCHEME HAS CHANGED

        The SConsignFile() function now uses an internally-supplied
        SCons.dblite module as the default DB scheme for the .sconsign file.
        If you are using the SConsignFile() function without an explicitly
        specified dbm_module argument, this will cause all of your targets
        to be recompiled the first time you use SCons 0.96.  To preserve the
        previous behavior, specify the "anydbm" module explicitly:

            import anydbm
            SConsignFile('.sconsign_file_name', anydbm)

    --  INTERNAL .sconsign FILE FORMAT HAS CHANGED

        The internal format of .sconsign files has been changed.  This might
        cause warnings about "ignoring corrupt .sconsign files" and rebuilds
        when you use SCons 0.96 for the first time in a tree that was
        previously built with SCons 0.95 or earlier.

    --  INTERFACE CHANGE OF scan_check FUNCTION TO CUSTOM SCANNERS

        The scan_check function that can be supplied to a custom Scanner now
        must take two arguments, the Node to be checked and a construction
        environment.  It previously only used the Node as an argument.

    --  DEFAULT SCANNERS NO LONGER HEED INTERNAL Scanner.add_skey() METHOD

        The internal Scanner.add_skey() method no longer works for the
        default scanners, which now use construction variables to hold their
        lists of suffixes.  If you had a custom Tool specification that was
        reaching into the internals in this way to add a suffix to one of
        the following scanner, you must now add the suffix to a construction
        environment through which you plan to call the scanner, as follows:

            CScan.add_skey('.x')       => env.Append(CPPSUFFIXES = ['.x'])
            DScan.add_skey('.x')       => env.Append(DSUFFIXES = ['.x'])
            FortranScan.add_skey('.x') => env.Append(FORTRANSUFFIXES = ['.x'])

    --  KEYWORD ARGUMENTS TO Builder() HAVE BEEN REMOVED

        The "node_factory" and "scanner" keyword arguments to the Builder()
        function have been removed.  In their place, the separate and more
        flexible "target_factory," "source_factory," "target_scanner" and
        "source scanner" keywords should be used instead.

    --  ALL-DIGIT FILE "EXTENSIONS" ARE NOW PART OF THE FILE BASENAME

        SCons now treats file "extensions" that contain all digits (for
        example, "file.123") as part of the file basename, for easier
        handling of version numbers in the names of shared libraries
        and other files.  Builders will now add their file extensions to
        file names specified with all-digit extensions.  If you need to
        generate a file with an all-digit extension using a Builder that
        adds a file extension, you can preserve the previous behavior by
        wrapping the file name in a File() call.

    --  Append()/Prepend() METHODS CHANGED WHEN USING UserList OBJECTS

        The behavior of the env.Append() and env.Prepend() methods has
        changed when appending a string value to a UserList, or vice versa.
        They now behave like normal Python addition of a string to
        a UserList.  Given an initialization and an env.Append() call like:

            env = Environment(VAR1=UserList(['foo']), VAR2='foo')
            env.Append(VAR1='bar', VAR2=UserList(['bar'])

        The resulting values of $VAR1 and $VAR2 will now be ['foo', 'b',
        'a', 'r'] and ['f', 'o', 'o', 'bar'], respectively.  This is because
        Python UserList objects treat strings as sequences of letters when
        adding them to the value of the UserList.

        The old behavior of yielding $VAR1 and $VAR2 values of ['foo',
        'bar'] when either variable is a UserList object now requires that
        the string variables be enclosed in a list:

            env = Environment(VAR1=UserList(['foo']), VAR2=['foo'])
            env.Append(VAR1='bar', VAR2=UserList(['bar']))

        Note that the SCons behavior when appending to normal lists has
        *not* changed, and the behavior of all of the default values that
        SCons uses to initialize all construction variables has *not*
        changed.  This change *only* affects any cases where you explicitly
        use UserList objects to initialize or append to a variable.

  Please note the following planned, future changes:

    --  SCANNER NAMES HAVE BEEN DEPRECATED AND WILL BE REMOVED

        Several internal variable names in SCons.Defaults for various
        pre-made default Scanner objects have been deprecated and will
        be removed in a future revision.  In their place are several new
        global variable names that are now part of the publicly-supported
        interface:

            NEW NAME              DEPRECATED NAME
            --------              ----------------------------
            CScanner              SCons.Defaults.CScan
            DSCanner              SCons.Defaults.DScan
            SourceFileScanner     SCons.Defaults.ObjSourceScan
            ProgramScanner        SCons.Defaults.ProgScan

        Of these, only ObjSourceScan was probably used at all, to add
        new mappings of file suffixes to other scanners for use by the
        Object() Builder.  This should now be done as follows:

            SourceFileScanner.add_scanner('.x', XScanner)

    --  THE env.Copy() METHOD WILL CHANGE OR GO AWAY ENTIRELY

        The env.Copy() method (to make a copy of a construction
        environment) is being replaced by the env.Clone() method.

        In some future release, a deprecation warning will be added
        to current uses of the env.Copy() method.  At some point after
        the deprecation warning, the env.Copy() method will either be
        removed entirely or have its behavior changed.

        You can prepare for this by changing all your uses of env.Copy()
        to env.Clone(), which has the exact same calling arguments.

        NOTE:  CHANGING USES OF env.Copy() TO env.Clone() WILL MAKE YOUR
        SConscript FILES NOT WORK ON EARLIER VERSIONS OF SCons.

        If you change SConscript files in software that you make available
        for download or otherwise distribute, other users may try to
        build your software with an earlier version of SCons that does
        not have the env.Clone() method.  We recommend preparing for
        this in one of two ways:

            --  Make your SConscript files backwards-compatible by
                including the following code near the beginning of your
                top-level SConstruct file:

                    import SCons.Environment
                    try:
                        SCons.Environment.Environment.Clone
                    except AttributeError:
                        SCons.Environment.Environment.Clone = \
                              SCons.Environment.Environment.Copy

            --  Use the EnsureSConsVersion() function to provide a
                descriptive error message if your SConscript files
                are executed by an earlier version of SCons:

                    EnsureSConsVersion(0, 96, 93)

  SCons is developed with an extensive regression test suite, and a
  rigorous development methodology for continually improving that suite.
  Because of this, SCons is of sufficient quality that you can use it
  for real work.  The "beta" status of the release reflects that we
  still may change interfaces in future releases, which may require
  modifications to your SConscript files.  We strive to hold these
  changes to a minimum.

  Nevertheless, please heed the following disclaimers:

    - Please report any bugs or other problems that you find to our bug
      tracker at our SourceForge project page:

      http://sourceforge.net/tracker/?func=add&group_id=30337&atid=398971

      We have a reliable bug-fixing methodology already in place and
      strive to respond to problems relatively quickly.

    - Documentation is spottier than we'd like.  You may need to dive
      into the source code to figure out how to do something.  Asking
      questions on the scons-users mailing list is also welcome.  We
      will be addressing the documentation in upcoming releases, but
      would be more than glad to have your assistance in correcting this
      problem... :-)

      In particular, the "SCons Design" documentation on the SCons web
      site is currently out of date, as we made significant changes to
      portions of the interface as we figured out what worked and what
      didn't during implementation.

    - There may be performance issues.  Improving SCons performance
      is an ongoing priority.  If you still find the performance
      unacceptable, we would very much like to hear from you and learn
      more about your configuration so we can optimize the right things.

    - Error messages don't always exist where they'd be helpful.
      Please let us know about any errors you ran into that would
      have benefitted from a (more) descriptive message.

  KNOWN PROBLEMS IN THIS RELEASE:

    For a complete list of known problems, consult the SCons Issue Tracker
    at tigris.org:

        http://scons.tigris.org/project_issues.html

    - Support for parallel builds (-j) does not work on WIN32 systems
      prior to *official* Python release 2.2 (not 2.2 pre-releases).

      Prior to Python 2.2, there is a bug in Python's Win32
      implementation such that when a thread spawns an external command,
      it blocks all threads from running.  This breaks the SCons
      multithreading architecture used to support -j builds.

      We have included a patch file, os_spawnv_fix.diff, that you can
      use if you you want to fix your version of Python to support
      parallel builds in SCons.

    - Again, the "SCons Design" documentation on the SCons web
      site is currently out of date.  Take what you read there with a
      grain of salt.

    - On Win32 systems, you must put a space between the redirection
      characters < and >, and the specified files (or construction
      variable expansions):

        command < $SOURCE > $TARGET

      If you don't supply a space (for example, "<$SOURCE"), SCons will
      not recognize the redirection.

    - MSVC .res files are not rebuilt when icons change.

    - The -c option does not clean up .sconsign files or directories
      created as part of the build, and also does not clean up
      SideEffect files (for example, Visual Studio .pdb files).

    - Switching content signatures from "MD5" to "timestamp" and back
      again can cause unusual errors.  These errors can be cleared up by
      removing all .sconsign files.

    - When using multiple Repositories, changing the name of an include
      file can cause an old version of the file to be used.

    - There is currently no way to force use of a relative path (../*)
      for directories outside the top-level SConstruct file.

    - The Jar() Builder will, on its second or subsequent invocation,
      package up the .sconsign files that SCons uses to track signatures.
      You can work around this by using the SConsignFile() function
      to collect all of the .sconsign information into a single file
      outside of the directory being packaged by Jar().

    - SCons does not currently have a way to detect that an intermediate
      file has been corrupted from outside and should be rebuilt.

    - Unicode characters in path names do not work in all circumstances.

    - SCons does not currently automatically check out SConstruct or
      SConscript files from SCCS, RCS or BitKeeper.

    - No support yet for the following planned command-line options:

         -d -e -l --list-actions --list-derived --list-where
         -o --override -p -r -R -w --write-filenames
         -W --warn-undefined-variables



Thank you for your interest, and please let us know how we can help
improve SCons for your needs.

Steven Knight
knight at baldmt dot com
http://www.baldmt.com/~knight/

With plenty of help from the SCons Development team:
        Chad Austin
        Charles Crain
        Steve Leblanc
        Gary Oberbrunner
        Anthony Roach
        Greg Spencer
        Christoph Wiedemann
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.