summaryrefslogtreecommitdiffstats
path: root/src/RELEASE.txt
blob: d87808b6b7aab77a8df064477376381ed5bb477e (plain)
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
# __COPYRIGHT__
# __FILE__ __REVISION__ __DATE__ __DEVELOPER__


                 SCons - a software construction tool

                            Release Notes


This is an alpha 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.10 - Thu, 16 Jan 2003 04:11:46 -0600

  This is the tenth alpha 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.10:

    - The default suffix for shared object files when using gcc has now
      been changed to '.os'.  This makes library builds more convenient
      by allowing both static (compiled without -fPIC) and shared object
      files (compiled with -fPIC) to exist side-by-side.  If you want to
      preserve the old behavior of using .o files for shared objects,
      you must now explicitly reset the SHOBJSUFFIX value in your
      construction environment as follows:

        env = Environment(SHOBJSUFFIX = '.o')

  - Setting the BUILDERS construction variable now properly clears
    the previous Builder attributes from the construction Environment.
    Before, you could initialize BUILDERS like so:

        env = Environment(BUILDERS = {'NewBuilder' : foo})

    And still use the canned default Builders like env.Program(),
    env.Object(), env.StaticLibrary(), etc.  No more.  Beginning with
    SCons 0.10, an initialization like that above will create an
    Environment with only the env.NewBuilder() Builder.

    So now, if you want to use a new builder in addition to the default
    builders, you should explicitly append your new builder to the
    existing ones using techniques like the following:

        env.Append(BUILDERS = {'NewBuilder' : foo})

        env['BUILDERS']['newbuilder'] = foo

  - An "env" argument has been added to the calls to all functions that
    return a string for a Python function Action.  This makes the string
    function and build function calls take the same arguments:

        def build_it(target, source, env):
            # build the target from the source
            return 0

        def string_it(target, source, env):
            return "building '%s' from '%s'" % (target[0], source[0])

        a = Action(build_it, string_it)

    If you have defined a strfunction() for a Python function Action,
    you will need to add a third "env" argument to your function call.

  Please note the following important changes since release 0.09:

    - The Scanner interface has been changed to make it easier to

      write user-defined Scanners and to eliminate unnecessary Scanner
      calls.  This required changing the meaning of the third argument
      passed to your user-defined scanner functions.  The third argument
      was formerly the target node whose build was causing a scan of the
      current node specified as the first argument:

        def scanner_function(node, env, target):

      The third argument is now the path of directories that can be
      searched for files found during the scan of the current node:

        def scanner_function(node, env, path):

      If you did not actually use the third argument in your scanner
      function, which should be the case for most definitions, you do
      not need to change your scanner function.  (You may, however, wish
      to change the name of the third argument from "target" to "path"
      to reflect the changed meaning and avoid misleading anyone who
      looks at your SConscript files.)

    - The .sconsign file format has been changed from ASCII to a pickled
      Python data structure.  This improves performance and future
      extensibility, but means that the first time you execute SCons
      0.10 on an already-existing source tree built with SCons 0.09 or
      earlier, SCons will report for every .sconsign file in the tree:

      	SCons warning: Ignoring corrupt .sconsign file: xxx

      These warnings are normal in this situation and can be safely
      ignored.

    - The format of all error and warning messages has been made
      consistent.  All error messages now begin with "scons: ***"
      and all warning messages now begin with "scons: warning:".

    - SCons now prints a description of Python functions that are
      invoked to build a target.

  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 "alpha" 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:

    - There may, of course, be bugs.  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 put space (for example, "<$SOURCE"), SCons will not
      recognize the redirection.

    - Executing the -u or -U option from a source directory that has an
      associated BuildDir() does not build the targets in the BuildDir().

    - No support yet for the following future features:

        - No support for caching built files.

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

             -d -e -l --list-actions --list-derived --list-where
             -o --override -p -r -R --random -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
        Anthony Roach
        Terrel Shumway