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
|
# __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.96 - XXX
This is the seventh 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.95:
- 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)
- The internal format of .sconsign files has been changed.
This may cause warnings about "ignoring corrupt .sconsign files"
and rebuilds when you use SCons 0.96 for the first time in a tre
that was previously gbuilt with SCons 0.95 or earlier.
- 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.
- 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'])
- The internal "node_factory" keyword argument has been removed;
the seperate and more flexible "target_factory" and "source_factory"
keywords should be used instead.
- 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 important changes since release 0.94:
- The internal Python function used by the Zip Builder in Python
releases 1.6 or later now compresses the resulting .zip file
by default. The old behavior of creating an uncompressed file
may be preserved by setting the new ZIPCOMPRESSION construction
variable to 0 (or zipfile.ZIP_STORED, if you import the
underlying zipfile module).
- The "overrides" keyword argument to calls to the Builder() function
used to create new Builder objects has been deprecated and will
be removed in a future release. The items in an "overrides"
dictionary should now be specified as keyword arguments:
# Old way, "overrides" is a dictionary:
Builder(action = 'cp $TDIR/$TARGET $SDIR/$SOURCE',
overrides = {'TDIR' : dir1, 'SDIR' : dir2})
# New way, items are specified as keyword arguments:
Builder(action = 'cp $TDIR/$TARGET $SDIR/$SOURCE',
TDIR = dir1, SDIR = dir2)
- The meaning of some of the values of the "mode" argument to
the SCons.Util.scons_subst() and SCons.Util.scons_subst_list()
functions have been swapped. The wrapper Environment.subst() and
Environment.subst_list() methods remain completely unchanged, so
this should have no external effect. (We've listed the change here
because it might cause a problem if you're reaching into the SCons
internals and calling either of these SCons.Util functions directly.)
Please note the following FUTURE changes that you may wish to prepare
for:
- When compiling with Microsoft Visual Studio, SCons currently adds
the ATL and MFC directories to the INCLUDE and LIB environment
variables by default. This default behavior will be changed in
a future release; the current plan is to change it for the 0.97
release (next release).
Whether or not the ATL and MFC directories are added to these
environment variables is now controlled by a new MSVS_USE_MFC_DIRS
*construction* variable. Setting this variable to a non-zero
value when you initialize an Environment will ensure that these
directories will be included in your external path(s) even when
the default behavior changes:
env = Environment(MSVS_USE_MFC_DIRS = 1)
The MSVS_USE_MFC_DIRS variable may, of course, be set to 0 (or
None) to prevent SCons from adding the ATL and MFC directories to
the INCLUDE and LIB environment variables.
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 bug tracker
page at SourceForge:
http://sourceforge.net/tracker/?atid=398971&group_id=30337&func=browse
- 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.
- If a file is specified to be built in multiple ways, the last
processed builder specification overwrites all other builders,
without any warning.
- 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.
- People have reported problems with SCons not stopping a build when
an interrupt (CTRL+C) is received. A fix was checked in to 0.11
that should fix this behavior on many systems, but there are
issues with the underlying Python os.system() call that suggest
this fix does not work on all systems or in all circumstances.
We're working to try to find a universal solution.
- Modifying a construction environment in a subsidiary SConscript
file modifies the global environment.
- 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.
- A stray source file in a BuildDir can prevent targets from being
(re)built when they should.
- SCons does not automatically rebuild LaTeX files when the file
has an undefined reference on the first build.
- SideEffect() files are not retrieved properly from a CacheDir(),
and can lead to a stack trace.
- Use of --implicit-cache with TargetSignatures('content') can,
for some changes, not rebuild a file when necessary.
- SCons does not currently automatically check out SConstruct or
SConscript files from SCCS, RCS or BitKeeper.
- The Command() global function (specified without a construction
environment) is broken.
- 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
|