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
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
|
# __COPYRIGHT__
# __FILE__ __REVISION__ __DATE__ __DEVELOPER__
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.98 - Sun, 30 Mar 2008 23:33:05 -0700
This is the ninth 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.0d20071212:
-- SUPPORT FOR PYTHON VERSIONS BEFORE 2.2 IS NOW DEPRECATED
SCons now prints the following warning when it is run by any
Python 1.5, 2.0 or 2.1 release or sub-release:
scons: warning: Support for pre-2.2 Python (VERSION) is deprecated.
If this will cause hardship, contact dev@scons.tigris.org.
You may disable all warnings about deprecated features by adding
the option "--warn=no-deprecated" to the command line or to the
$SCONSFLAGS environment variable:
$ scons --warn=no-deprecated
Using '--warn=no-deprecated' is compatible with earlier versions
of SCons.
You may also, as of this version of SCons, disable all warnings
about deprecated features by adding the following to any
SConscript file:
SetOption('warn', 'no-deprecated')
You may disable only the specific warning about running under
a deprecated Python version by adding the following to any
SConscript file:
SetOption('warn', 'no-python-version')
The warning may also be suppressed on the command line:
$ scons --warn=no-python-version
Or by specifying the --warn=no-python-version option in the
$SCONSFLAGS environment variable.
Using SetOption('warn', ...), and the 'no-python-version'
command-line option for suppressing this specific warning,
are *not* backwards-compatible to earlier versions of SCons.
-- THE env.Copy() METHOD IS NOW OFFICIALLY DEPRECATED
The env.Copy() method is now officially deprecated and will
be removed in a future release. Using the env.Copy() method
now generates the following message:
scons: warning: The env.Copy() method is deprecated; use the env.Clone() method instead.
You may disable all warnings about deprecated features by adding
the option "--warn=no-deprecated" to the command line or to the
$SCONSFLAGS environment variable:
$ scons --warn=no-deprecated
Using '--warn=no-deprecated' is compatible with earlier versions
of SCons.
You may also, as of this version of SCons, disable all warnings
about deprecated features by adding the following to any
SConscript file:
SetOption('warn', 'no-deprecated')
You may disable only the specific warning about the deprecated
env.Copy() method by adding the following to any SConscript
file:
SetOption('warn', 'no-deprecated-copy')
The warning may also be suppressed on the command line:
$ scons --warn=no-deprecated-copy
Or by specifying the --warn=no-deprecated-copy option in the
$SCONSFLAGS environment variable.
Using SetOption('warn', ...), and the 'no-deprecated-copy'
command-line option for suppressing this specific warning,
are *not* backwards-compatible to earlier versions of SCons.
-- THE --debug=dtree, --debug=stree AND --debug=tree OPTIONS ARE DEPRECATED
The --debug=dtree, --debug=stree and --debug=tree methods
are now officially deprecated and will be removed in a
future release. Using these options now generate a warning
message recommending use of the --tree=derived, --tree=all,status
and --tree=all options, respectively.
You may disable these warnings, and all warnings about
deprecated features, by adding the option "--warn=no-deprecated"
to the command line or to the $SCONSFLAGS environment
variable:
$ scons --warn=no-deprecated
Using '--warn=no-deprecated' is compatible with earlier versions
of SCons.
-- THE TargetSignatures() AND SourceSignatures() FUNCTIONS ARE DEPRECATED
The TargetSignatures() and SourceSignatures() functions,
and their corresponding env.TargetSignatures() and
env.SourceSignatures() methods, are now officially deprecated
and will be be removed in a future release. Using ahy of
these functions or methods now generates a message
similar to the following:
scons: warning: The env.TargetSignatures() method is deprecated;
convert your build to use the env.Decider() method instead.
You may disable all warnings about deprecated features by adding
the option "--warn=no-deprecated" to the command line or to the
$SCONSFLAGS environment variable:
$ scons --warn=no-deprecated
Using '--warn=no-deprecated' is compatible with earlier versions
of SCons.
You may also, as of this version of SCons, disable all warnings
about deprecated features by adding the following to any
SConscript file:
SetOption('warn', 'no-deprecated')
You may disable only the specific warning about the use of
TargetSignatures() or SourceSignatures() by adding the
following to any SConscript file:
SetOption('warn', 'no-deprecated-target-signatures')
SetOption('warn', 'no-deprecated-source-signatures')
The warnings may also be suppressed on the command line:
$ scons --warn=no-deprecated-target-signatures --warn=no-deprecated-source-signatures
Or by specifying these options in the $SCONSFLAGS environment
variable.
Using SetOption('warn', ...), or the command-line options
for suppressing these warnings, is *not* backwards-compatible
to earlier versions of SCons.
-- File(), Dir() and Entry() NOW RETURN A LIST WHEN THE INPUT IS A SEQUENCE
Previously, if these methods were passed a list, the list was
substituted and stringified, then passed as a single string to
create a File/Dir/Entry Node. This rarely if ever worked with
more than one element in the list. They now return a list of
Nodes when passed a list.
One case that works differently now is a passing in a
single-element sequence; that formerly was stringified
(returning its only element) and then a single Node would be
returned. Now a single-element list containing the Node will
be returned, for consistency.
-- THE env.subst() METHOD NOW RETURNS A LIST WHEN THE INPUT IS A SEQUENCE
The env.subst() method now returns a list with the elements
expanded when given a list as input. Previously, the env.subst()
method would always turn its result into a string.
This behavior was changed because it interfered with being able
to include things like lists within the expansion of variables
like $CPPPATH and then have SCons understand that the elements
of the "internal" lists still needed to be treated separately.
This would cause a $CPPPATH list like ['subdir1', 'subdir']
to show up in a command line as "-Isubdir1 subdir".
-- THE Jar() BUILDER NOW USES THE Java() BUILDER CLASSDIR BY DEFAULT
By default, the Jar() Builder will now use the class directory
specified when the Java() builder is called. So the following
input:
classes = env.Java('classes', 'src')
env.Jar('out.jar', classes)
Will cause "-C classes" to be passed the "jar" command invocation,
and the Java classes in the "out.jar" file will not be prefixed
"classes/".
Explicitly setting the $JARCHDIR variable overrides this default
behavior. The old behavior of not passing any -C option to the
"jar" command can be preserved by explicitly setting $JARCHDIR
to None:
env = Environment(JARCHDIR = None)
The above setting is compatible with older versions of SCons.
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:
-- THE BuildDir() METHOD AND FUNCTION WILL BE DEPRECATED
The env.BuildDir() method and BuildDir() function are being
replaced by the new env.VariantDir() method and VariantDir()
function.
In some future release a deprecation warning will be added
to existing uses of the env.BuildDir() method and BuildDir()
function. At some point after the deprecation warning, the
env.Builder() method and BuildDir() function will either
be removed entirely or have their behavior changed.
You can prepare for this by changing all your uses of the
env.BuildDir() method to env.VariantDir() and uses of the
global BuildDir() function to VariantDir(). If you use a
named keyword argument of "build_dir" when calling
env.BuildDir() or BuildDir():
env.BuildDir(build_dir='opt', src_dir='src')
The keyword must be changed to "variant_dir":
env.VariantDir(variant_dir='opt', src_dir='src')
NOTE: CHANGING USES OF env.BuildDir() AND BuildDir() to
env.VariantDir() AND VariantDir() IS NOT BACKWARDS COMPATIBLE
TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript FILES
WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER MAKING
THIS CHANGE.
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.VariantDir() method or
VariantDir() fnction. 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.VariantDir
except AttributeError:
SCons.Environment.Environment.VariantDir = \
SCons.Environment.Environment.BuildDir
-- Use the EnsureSConsVersion() function to provide a
descriptive error message if your SConscript files
are executed by an earlier version of SCons:
EnsureSConsVersion(0, 98)
-- THE SConscript() "build_dir" KEYWORD ARGUMENT WILL BE DEPRECATED
The "build_dir" keyword argument of the SConscript function
and env.SConscript() method are being replaced by a new
"variant_dir" keyword argument.
In some future release a deprecation warning will be added
to existing uses of the SConscript()/env.SConscript()
"build_dir" keyword argument. At some point after the
deprecation warning, support for this keyword argument will
be removed entirely.
You can prepare for this by changing all your uses of the
SConscript()/env.SConscript() 'build_dir" keyword argument:
SConscript('src/SConscript', build_dir='opt')
To use the new "variant_dir" keyword argument:
SConscript('src/SConscript', variant_dir='opt')
NOTE: USING THE NEW "variant_dir" KEYWORD IS NOT BACKWARDS
COMPATIBLE TO VERSIONS OF SCons BEFORE 0.98. YOUR SConscript
FILES WILL NOT WORK ON EARLIER VERSIONS OF SCons AFTER
MAKING THIS CHANGE.
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 support the "variant_dir" keyword.
If you can insist that users use a recent version of SCons
that supports "variant_dir", we recommend using the
EnsureSConsVersion() function to provide a descriptive error
message if your SConscript files are executed by an earlier
version of SCons:
EnsureSConsVersion(0, 98)
If you want to make sure that your SConscript files will
still work with earlier versions of SCons, then your best
bet is to continue to use the "build_dir" keyword until the
support is removed (which, in all likelihood, won't happen
for quite some time).
-- 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.
As of SCons 0.98, a deprecation warning has been added to
current uses of the env.Copy() method. At some point in
the future, 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 VERSIONS OF SCons BEFORE
0.96.93.
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).
- 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
|