Merged revisions 5065-5066 via svnmerge from
[scons:mainlinemirror.git] / README
1                  SCons - a software construction tool
2
3 Welcome to the SCons development tree.  The real purpose of this tree
4 is to package SCons for production distribution in a variety of formats,
5 not just to hack SCons code.
6
7 If all you want to do is install and run SCons, it will be easier for you
8 to download and install the scons-{version}.tar.gz or scons-{version}.zip
9 package rather than to work with the packaging logic in this tree.
10
11 To the extent that this tree is about building SCons packages, the *full*
12 development cycle is not just to test the code directly, but to package
13 SCons, unpack the package, "install" SCons in a test subdirectory,
14 and then to run the tests against the unpacked and installed software.
15 This helps eliminate problems caused by, for example, failure to update
16 the list of files to be packaged.
17
18 For just working on making an individual change to the SCons source,
19 however, you don't actually need to build or install SCons; you
20 *can* actually edit and execute SCons in-place.  See the following
21 sections below for more information:
22
23     MAKING CHANGES
24         How to edit and execute SCons in-place.
25
26     DEBUGGING
27         Tips for debugging problems in SCons.
28
29     TESTING
30         How to use the automated regression tests.
31
32     DEVELOPMENT WORKFLOW
33         An example of how to put the edit/execute/test pieces
34         together in a reasonable development workflow.
35
36
37 LATEST VERSION
38 ==============
39
40 Before going further, you can check that this package you have is the
41 latest version at the SCons download page:
42
43         http://www.scons.org/download.html
44
45
46 EXECUTION REQUIREMENTS
47 ======================
48
49 Running SCons requires Python version 2.4 or later.  There should be
50 no other dependencies or requirements to run SCons.
51
52 The default SCons configuration assumes use of the Microsoft Visual C++
53 compiler suite on WIN32 systems, and assumes a C compiler named 'cc',
54 a C++ compiler named 'c++', and a Fortran compiler named 'g77' (such
55 as found in the GNU C compiler suite) on any other type of system.
56 You may, of course, override these default values by appropriate
57 configuration of Environment construction variables.
58
59 By default, SCons knows how to search for available programming tools
60 on various systems--see the SCons man page for details.  You may,
61 of course, override the default SCons choices made by appropriate
62 configuration of Environment construction variables.
63
64
65 INSTALLATION REQUIREMENTS
66 =========================
67
68 Nothing special.
69
70
71 EXECUTING SCONS WITHOUT INSTALLING
72 ==================================
73
74 You can execute the local SCons directly from the src/ subdirectory by
75 first setting the SCONS_LIB_DIR environment variable to the local
76 src/engine subdirectory, and then executing the local src/script/scons.py
77 script to populate the build/scons/ subdirectory.  You would do this as
78 follows on a Linux or UNIX system (using sh or a derivative like bash or
79 ksh):
80
81         $ setenv MYSCONS=`pwd`/src
82         $ setenv SCONS_LIB_DIR=$MYSCONS/engine
83         $ python $MYSCONS/script/scons.py [arguments]
84
85 Or on Windows:
86
87         C:\scons>set MYSCONS=%cd%\src
88         C:\scons>set SCONS_LIB_DIR=%MYSCONS%\engine
89         C:\scons>python %MYSCONS%\script\scons.py [arguments]
90
91 An alternative approach is to skip the above and use:
92
93         $ python bootstrap.py [arguments]
94
95 bootstrap.py keeps the src/ subdirectory free of compiled Python (*.pyc or
96 *.pyo) files by copying the necessary SCons files to a local bootstrap/
97 subdirectory and executing it from there.
98
99 You can use the -C option to have SCons change directory to another
100 location where you already have a build configuration set up.
101
102     $ python bootstrap.py -C /some/other/location [arguments]
103
104 For simplicity in the following examples, we will only show the
105 bootstrap.py approach.
106
107
108 INSTALLATION
109 ============
110
111     NOTE: You don't need to build SCons packages or install SCons if
112     you just want to work on developing a patch.  See the sections
113     about MAKING CHANGES and TESTING below if you just want to submit
114     a bug fix or some new functionality.  See the sections below about
115     BUILDING PACKAGES and TESTING PACKAGES if your enhancement involves
116     changing the way in which SCons is packaged and/or installed on an
117     end-user system.
118
119 Assuming your system satisfies the installation requirements in the
120 previous section, install SCons from this package by first populating
121 the build/scons/ subdirectory.  (For an easier way to install SCons,
122 without having to populate this directory, use the scons-{version}.tar.gz
123 or scons-{version}.zip package.)
124
125 Populate build/scons/ using a pre-installed SCons
126 -------------------------------------------------
127
128 If you already have an appropriate version of SCons installed on your
129 system, populate the build/scons/ directory by running:
130
131         $ scons build/scons
132
133 Populate build/scons/ using the SCons source
134 --------------------------------------------
135
136 You can also use this version of SCons to populate its own build directory
137 by using a supplied bootstrap.py script (see the section above about
138 EXECUTING SCONS WITHOUT INSTALLING):
139
140         $ python bootstrap.py build/scons
141
142 Install the built SCons files
143 -----------------------------
144
145 Any of the above commands will populate the build/scons/ directory with
146 the necessary files and directory structure to use the Python-standard
147 setup script as follows on Linux or UNIX:
148
149         # cd build/scons
150         # python setup.py install
151
152 Or on Windows:
153
154         C:\scons\>cd build\scons
155         C:\scons\build\scons>python setup.py install
156
157 By default, the above commands will do the following:
158
159     --  Install the version-numbered "scons-2.0.0" and "sconsign-2.0.0"
160         scripts in the default system script directory (/usr/bin or
161         C:\Python*\Scripts, for example).  This can be disabled by
162         specifying the "--no-version-script" option on the command
163         line.
164
165     --  Install scripts named "scons" and "sconsign" scripts in the
166         default system script directory (/usr/bin or C:\Python*\Scripts,
167         for example).  This can be disabled by specifying the
168         "--no-scons-script" option on the command line, which is useful
169         if you want to install and experiment with a new version before
170         making it the default on your system.
171
172         On UNIX or Linux systems, you can have the "scons" and "sconsign"
173         scripts be hard links or symbolic links to the "scons-2.0.0" and
174         "sconsign-2.0.0" scripts by specifying the "--hardlink-scons" or
175         "--symlink-scons" options on the command line.
176
177     --  Install "scons-2.0.0.bat" and "scons.bat" wrapper scripts in the
178         Python prefix directory on Windows (C:\Python*, for example).
179         This can be disabled by specifying the "--no-install-bat" option
180         on the command line.
181
182         On UNIX or Linux systems, the "--install-bat" option may be
183         specified to have "scons-2.0.0.bat" and "scons.bat" files installed
184         in the default system script directory, which is useful if you
185         want to install SCons in a shared file system directory that can
186         be used to execute SCons from both UNIX/Linux and Windows systems.
187
188     --  Install the SCons build engine (a Python module) in an
189         appropriate version-numbered SCons library directory
190         (/usr/lib/scons-2.0.0 or C:\Python*\scons-2.0.0, for example).
191         See below for more options related to installing the build
192         engine library.
193
194     --  Install the troff-format man pages in an appropriate directory
195         on UNIX or Linux systems (/usr/share/man/man1 or /usr/man/man1,
196         for example).  This can be disabled by specifying the
197         "--no-install-man" option on the command line.  The man pages
198         can be installed on Windows systems by specifying the
199         "--install-man" option on the command line.
200
201 Note that, by default, SCons does not install its build engine library
202 in the standard Python library directories.  If you want to be able to
203 use the SCons library modules (the build engine) in other Python
204 scripts, specify the "--standard-lib" option on the command line, as
205 follows:
206
207         # python setup.py install --standard-lib
208
209 This will install the build engine in the standard Python library
210 directory (/usr/lib/python*/site-packages or
211 C:\Python*\Lib\site-packages).
212
213 Alternatively, you can have SCons install its build engine library in a
214 hard-coded standalone library directory, instead of the default
215 version-numbered directory, by specifying the "--standalone-lib" option
216 on the command line, as follows:
217
218         # python setup.py install --standalone-lib
219
220 This is usually not recommended, however.
221
222 Note that, to install SCons in any of the above system directories,
223 you should have system installation privileges (that is, "root" or
224 "Administrator") when running the setup.py script.  If you don't have
225 system installation privileges, you can use the --prefix option to
226 specify an alternate installation location, such as your home directory:
227
228         $ python setup.py install --prefix=$HOME
229
230 This will install SCons in the appropriate locations relative to
231 $HOME--that is, the scons script itself $HOME/bin and the associated
232 library in $HOME/lib/scons, for example.
233
234
235 MAKING CHANGES
236 ==============
237
238 Because SCons is implemented in a scripting language, you don't need to
239 build it in order to make changes and test them.
240
241 Virtually all of the SCons functionality exists in the "build engine,"
242 the src/engine/SCons subdirectory hierarchy that contains all of the
243 modules that make up SCons.  The src/script/scons.py wrapper script exists
244 mainly to find the appropriate build engine library and then execute it.
245
246 In order to make your own changes locally and test them by hand, simply
247 edit modules in the local src/engine/SCons subdirectory tree and use the
248 local bootstrap.py script (see the section above about EXECUTING SCONS
249 WITHOUT INSTALLING):
250
251     $ python bootstrap.py [arguments]
252
253 If you want to be able to just execute your modified version of SCons from
254 the command line, you can make it executable and add its directory to your
255 $PATH like so:
256
257     $ chmod 755 src/script/scons.py
258     $ export PATH=$PATH:`pwd`/src/script
259
260 You should then be able to run this version of SCons by just typing
261 "scons.py" at your UNIX or Linux command line.
262
263 Note that the regular SCons development process makes heavy use of
264 automated testing.  See the TESTING and DEVELOPMENT WORKFLOW sections
265 below for more information about the automated regression tests and how
266 they can be used in a development cycle to validate that your changes
267 don't break existing functionality.
268
269
270 DEBUGGING
271 =========
272
273 Python comes with a good interactive debugger.  When debugging changes
274 by hand (i.e., when not using the automated tests), you can invoke SCons
275 under control of the Python debugger by specifying the --debug=pdb option:
276
277     $ scons --debug=pdb [arguments]
278     > /home/knight/SCons/src/engine/SCons/Script/Main.py(927)_main()
279     -> default_warnings = [ SCons.Warnings.CorruptSConsignWarning,
280     (Pdb) 
281
282 Once in the debugger, you can set breakpoints at lines in files in the
283 build engine modules by providing the path name of the file relative to
284 the src/engine subdirectory (that is, including the SCons/ as the first
285 directory component):
286
287     (Pdb) b SCons/Tool/msvc.py:158
288
289 The debugger also supports single stepping, stepping into functions,
290 printing variables, etc.
291
292 Trying to debug problems found by running the automated tests (see the
293 TESTING section, below) is more difficult, because the test automation
294 harness re-invokes SCons and captures output. Consequently, there isn't an
295 easy way to invoke the Python debugger in a useful way on any particular
296 SCons call within a test script.
297
298 The most effective technique for debugging problems that occur during an
299 automated test is to use the good old tried-and-true technique of adding
300 statements to print tracing information.  But note that you can't just use
301 "print" statement, or even "sys.stdout.write()," because those change the
302 SCons output, and the automated tests usually look for matches of specific
303 output strings to decide if a given SCons invocations passes the test.
304
305 To deal with this, SCons supports a Trace() function that (by default)
306 will print messages to your console screen ("/dev/tty" on UNIX or Linux,
307 "con" on Windows).  By adding Trace() calls to the SCons source code:
308
309     def sample_method(self, value):
310         from SCons.Debug import Trace
311         Trace('called sample_method(%s, %s)\n' % (self, value))
312
313 You can then run automated tests that print any arbitrary information
314 you wish about what's going on inside SCons, without interfering with
315 the test automation.
316
317 The Trace() function can also redirect its output to a file, rather than
318 the screen:
319
320     def sample_method(self, value):
321         from SCons.Debug import Trace
322         Trace('called sample_method(%s, %s)\n' % (self, value),
323               file='trace.out')
324
325 Where the Trace() function sends its output is stateful: once you use the
326 "file=" argument, all subsequent calls to Trace() send their output to
327 the same file, until another call with a "file=" argument is reached.
328
329
330 TESTING
331 =======
332
333 Tests are run by the runtest.py script in this directory.
334
335 There are two types of tests in this package:
336
337     Unit tests for individual SCons modules live underneath the
338     src/engine/ subdirectory and are the same base name as the module
339     with "Tests.py" appended--for example, the unit test for the
340     Builder.py module is the BuilderTests.py script.
341
342     End-to-end tests of SCons live in the test/ subdirectory.
343
344 You may specifically list one or more tests to be run:
345
346         $ python runtest.py src/engine/SCons/BuilderTests.py
347
348         $ python runtest.py test/option-j.py test/Program.py
349
350 You also use the -f option to execute just the tests listed in a specified
351 text file:
352
353         $ cat testlist.txt
354         test/option-j.py
355         test/Program.py
356         $ python runtest.py -f testlist.txt
357
358 One test must be listed per line, and any lines that begin with '#'
359 will be ignored (allowing you, for example, to comment out tests that
360 are currently passing and then uncomment all of the tests in the file
361 for a final validation run).
362
363 The runtest.py script also takes a -a option that searches the tree for
364 all of the tests and runs them:
365
366         $ python runtest.py -a
367
368 If more than one test is run, the runtest.py script prints a summary
369 of how many tests passed, failed, or yielded no result, and lists any
370 unsuccessful tests.
371
372 The above invocations all test directly the files underneath the src/
373 subdirectory, and do not require that a build be performed first.  The
374 runtest.py script supports additional options to run tests against
375 unpacked packages in the build/test-*/ subdirectories.  See the "TESTING
376 PACKAGES" section below.
377
378
379 DEVELOPMENT WORKFLOW
380 ====================
381
382     CAVEAT:  The point of this section isn't to describe one dogmatic
383     workflow.  Just running the test suite can be time-consuming, and
384     getting a patch to pass all of the tests can be more so.  If you're
385     genuinely blocked, it may make more sense to submit a patch with
386     a note about which tests still fail, and how.  Someone else may be
387     able to take your "initial draft" and figure out how to improve it
388     to fix the rest of the tests.  So there's plenty of room for use of
389     good judgement.
390
391 The various techniques described in the above sections can be combined
392 to create simple and effective workflows that allow you to validate
393 that patches you submit to SCons don't break existing functionality and
394 have adequate testing, thereby increasing the speed with which they can
395 be integrated.
396
397 For example, suppose your project's SCons configuration is blocked by
398 an SCons bug, and you decide you want to fix it and submit the patch.
399 Here's one possible way to go about doing that (using UNIX/Linux as the
400 development platform, Windows users can translate as appropriate)):
401
402     --  Change to the top of your checked-out SCons tree.
403
404     --  Confirm that the bug still exists in this version of SCons
405         by using the -C option to run the broken build:
406
407             $ python bootstrap.py -C /home/me/broken_project .
408
409     --  Fix the bug in SCons by editing appropriate module files
410         underneath src/engine/SCons.
411
412     --  Confirm that you've fixed the bug affecting your project:
413
414             $ python bootstrap.py -C /home/me/broken_project .
415
416     --  Test to see if your fix had any unintended side effects
417         that break existing functionality:
418
419             $ python runtest.py -a -o test.log
420
421         Be patient, there are more than 700 test scripts in the
422         whole suite.  If you are on UNIX/Linux, you can use:
423
424             $ python runtest.py -a | tee test.log
425
426         instead so you can monitor progress from your terminal.
427
428         If any test scripts fail, they will be listed in a summary at
429         the end of the log file.  Some test scripts may also report
430         NO RESULT because (for example) your local system is the wrong
431         type or doesn't have some installed utilities necessary to run
432         the script.  In general, you can ignore the NO RESULT list.
433
434     --  Cut-and-paste the list of failed tests into a file:
435
436             $ cat > failed.txt
437             test/failed-test-1.py
438             test/failed-test-2.py
439             test/failed-test-3.py
440             ^D
441             $
442
443     --  Now debug the test failures and fix them, either by changing
444         SCons, or by making necessary changes to the tests (if, for
445         example, you have a strong reason to change functionality, or
446         if you find that the bug really is in the test script itself).
447         After each change, use the runtest.py -f option to examine the
448         effects of the change on the subset of tests that originally
449         failed:
450
451             $ [edit]
452             $ python runtest.py -f failed.txt
453
454         Repeat this until all of the tests that originally failed
455         now pass.
456
457     --  Now you need to go back and validate that any changes you
458         made while getting the tests to pass didn't break the fix
459         you originally put in, and didn't introduce any *additional*
460         unintended side effects that broke other tests:
461
462             $ python bootstrap.py -C /home/me/broken_project .
463             $ python runtest.py -a -o test.log
464
465         If you find any newly-broken tests, add them to your "failed.txt"
466         file and go back to the previous step.
467
468 Of course, the above is only one suggested workflow.  In practice, there
469 is a lot of room for judgment and experience to make things go quicker.
470 For example, if you're making a change to just the Java support, you
471 might start looking for regressions by just running the test/Java/*.py
472 tests instead of running all of "runtest.py -a".
473
474
475 BUILDING PACKAGES
476 =================
477
478 We use SCons (version 0.96.93 later) to build its own packages.  If you
479 already have an appropriate version of SCons installed on your system,
480 you can build everything by simply running it:
481
482         $ scons
483
484 If you don't have SCons version 0.96.93 later already installed on your
485 system, you can use the supplied bootstrap.py script (see the section
486 above about EXECUTING SCONS WITHOUT INSTALLING):
487
488         $ python bootstrap.py build/scons
489
490 Depending on the utilities installed on your system, any or all of the
491 following packages will be built:
492
493         build/dist/scons-2.0.0-1.noarch.rpm
494         build/dist/scons-2.0.0-1.src.rpm
495         build/dist/scons-2.0.0.linux-i686.tar.gz
496         build/dist/scons-2.0.1.beta.20100627.tar.gz
497         build/dist/scons-2.0.1.beta.20100627.win32.exe
498         build/dist/scons-2.0.1.beta.20100627.zip
499         build/dist/scons-doc-2.0.1.beta.20100627.tar.gz
500         build/dist/scons-local-2.0.1.beta.20100627.tar.gz
501         build/dist/scons-local-2.0.1.beta.20100627.zip
502         build/dist/scons-src-2.0.1.beta.20100627.tar.gz
503         build/dist/scons-src-2.0.1.beta.20100627.zip
504         build/dist/scons_1.3.0-1_all.deb
505
506 The SConstruct file is supposed to be smart enough to avoid trying to
507 build packages for which you don't have the proper utilities installed.
508 For example, if you don't have Debian packaging tools installed, it
509 should just not build the .deb package, not fail the build.
510
511 If you receive a build error, please report it to the scons-devel
512 mailing list and open a bug report on the SCons bug tracker.
513
514 Note that in addition to creating the above packages, the default build
515 will also unpack one or more of the packages for testing.
516
517
518 TESTING PACKAGES
519 ================
520
521 A full build will unpack and/or install any .deb, .rpm., .local.tar.gz,
522 .local.zip, .src.tar.gz, .src.zip, .tar.gz, and .zip packages into
523 separate build/test-*/ subdirectories.  (Of course, if a package was
524 not built on your system, it should not try to install it.)  The
525 runtest.py script supports a -p option that will run the specified tests
526 (individually or collectively via the -a option) against the unpacked
527 build/test-/* subdirectory:
528
529         $ python runtest.py -p deb
530
531         $ python runtest.py -p rpm
532
533         $ python runtest.py -p local-tar-gz
534
535         $ python runtest.py -p local-zip
536
537         $ python runtest.py -p src-tar-gz
538
539         $ python runtest.py -p src-zip
540
541         $ python runtest.py -p tar-gz
542
543         $ python runtest.py -p zip
544
545 (The canonical invocation is to also use the runtest.py -a option so
546 that all tests are run against the specified package.)
547
548
549 CONTENTS OF THIS PACKAGE
550 ========================
551
552 Not guaranteed to be up-to-date (but better than nothing):
553
554 bench/
555         A subdirectory for benchmarking scripts, used to perform timing
556         tests to decide what specific idioms are most efficient for
557         various parts of the code base.  We check these in so they're
558         available in case we have to revisit any of these decisions in
559         the future.
560
561 bin/
562         Miscellaneous utilities used in SCons development.  Right now,
563         some of the stuff here includes:
564
565             --  a copy of the script we use to translate an Aegis change
566                 into a CVS checkin
567             --  a script that runs pychecker on our source tree
568             --  a script that counts source and test files and numbers
569                 of lines in each
570             --  a script for synchronizing the Aegis tree to SourceForge
571             --  a prototype script for capturing sample SCons output
572                 in xml files
573             --  a script that can profile and time a packaging build of
574                 SCons itself
575             --  a copy of xml_export, which can retrieve project data
576                 from SourceForge
577             --  scripts and a Python module for translating the SCons
578                 home-brew XML documentation tags into DocBook and
579                 man page format
580
581 bootstrap.py
582         A build script for use with Aegis.  This collects a current copy
583         of SCons from the Aegis baseline directories in a bootstrap/
584         subdirectory, and then executes SCons with the supplied
585         command-line arguments.
586
587 build/
588         This doesn't exist yet if you're looking at a vanilla source
589         tree.  This is generated as part of our build process, and it's
590         where, believe it or not, we *build* everything.
591
592 config
593         The Aegis configuration, governing much of how we use Aegis to
594         build, test, control source, etc.
595
596 debian/
597         Files needed to construct a Debian package. The contents of this
598         directory are dictated by the Debian Policy Manual
599         (http://www.debian.org/doc/debian-policy). The package will not be
600         accepted into the Debian distribution unless the contents of this
601         directory satisfy the relevant Debian policies.
602
603 doc/
604         SCons documentation.  A variety of things here, in various
605         stages of (in)completeness.
606
607 gentoo/
608         Stuff to generate files for Gentoo Linux.
609
610 HOWTO/
611         Documentation of SCons administrative procedures (making a
612         change, releasing a new version).  Maybe other administrative
613         stuff in the future.
614
615 LICENSE
616         A copy of the copyright and terms under which SCons is
617         distributed (the Open Source Initiative-approved MIT license).
618
619 LICENSE-local
620         A copy of the copyright and terms under which SCons is
621         distributed for inclusion in the scons-local-{version} packages.
622         This is the same as LICENSE with a preamble that specifies
623         the licensing terms are for SCons itself, not any other
624         package that includes SCons.
625
626 QMTest/
627         The Python modules we use for testing, some generic modules
628         originating elsewhere and some specific to SCons.
629
630 README
631         What you're looking at right now.
632
633 README-local
634         A README file for inclusion in the scons-local-{version}
635         packages.  Similar to this file, but stripped down and modified
636         for people looking at including SCons in their shipped software.
637
638 rpm/
639         The .spec file for building our RPM packages.
640
641 runtest.py
642         Script for running SCons tests.  By default, this will run a
643         test against the code in the local src/ tree, so you don't
644         have to do a build before testing your changes.  Aegis uses
645         it with an option that requires that you've done a build
646         (aeb) before running tests.
647
648 SConstruct
649         The "Makefile" for the SCons distribution.
650
651         (It has been pointed out that it's hard to find the SCons API
652         in this SConstruct file, and that it looks a lot more like a
653         pure Python script than a build configuration file.  That's
654         mainly because all of the magick we have to perform to deal with
655         all of the different packaging formats requires a lot of pure
656         Python manipulation.  In other words, don't look at this file
657         for an example of how easy it is to use SCons to build "normal"
658         software.)
659
660 src/
661         Where the actual source code is kept, of course.
662
663 template/
664         Template files, used by Aegis to give you a head start when you
665         aenf or aent a new file.
666
667 test/
668         End-to-end tests of the SCons utility itself.  These are
669         separate from the individual module unit tests, which live
670         side-by-side with the modules under src/.
671
672
673 DOCUMENTATION
674 =============
675
676 See the src/RELEASE.txt file for notes about this specific release,
677 including known problems.  See the src/CHANGES.txt file for a list of
678 changes since the previous release.
679
680 The doc/man/scons.1 man page is included in this package, and contains a
681 section of small examples for getting started using SCons.
682
683 Additional documentation for SCons is available at:
684
685         http://www.scons.org/doc.html
686
687
688 LICENSING
689 =========
690
691 SCons is distributed under the MIT license, a full copy of which is
692 available in the LICENSE file. The MIT license is an approved Open
693 Source license, which means:
694
695         This software is OSI Certified Open Source Software.  OSI
696         Certified is a certification mark of the Open Source Initiative.
697
698 More information about OSI certifications and Open Source software is
699 available at:
700
701         http://www.opensource.org/
702
703
704 REPORTING BUGS
705 ==============
706
707 Please report bugs by following the detailed instructions on our Bug
708 Submission page:
709
710         http://scons.tigris.org/bug-submission.html
711
712 You can also send mail to the SCons developers' mailing list:
713
714         dev@scons.tigris.org
715
716 But even if you send email to the mailing list please make sure that you
717 ALSO submit a bug report to the project page bug tracker, because bug
718 reports in email often get overlooked in the general flood of messages.
719
720
721 MAILING LISTS
722 =============
723
724 An active mailing list for developers of SCons is available.  You may
725 send questions or comments to the list at:
726
727         dev@scons.tigris.org
728
729 You may request a subscription to the developer's mailing list by sending
730 email to:
731
732         dev-subscribe@scons.tigris.org
733
734 Subscription to the developer's mailing list is by approval.  In practice,
735 no one is refused list membership, but we reserve the right to limit
736 membership in the future and/or weed out lurkers.
737
738 There is also a low-volume mailing list available for announcements
739 about SCons.  Subscribe by sending email to:
740
741         announce-subscribe@scons.tigris.org
742
743 There are other mailing lists available for SCons users, for notification
744 of SCons code changes, and for notification of updated bug reports and
745 project documents.  Please see our mailing lists page for details.
746
747
748 DONATIONS
749 =========
750
751 If you find SCons helpful, please consider making a donation (of cash,
752 software, or hardware) to support continued work on the project.
753 Information is available at:
754
755         http://www.scons.org/donate.html
756
757
758 FOR MORE INFORMATION
759 ====================
760
761 Check the SCons web site at:
762
763         http://www.scons.org/
764
765
766 AUTHOR INFO
767 ===========
768
769 Steven Knight
770 knight at baldmt dot com
771 http://www.baldmt.com/~knight/
772
773 With plenty of help from the SCons Development team:
774         Chad Austin
775         Charles Crain
776         Bill Deegan
777         Steve Leblanc
778         Greg Noel
779         Gary Oberbrunner
780         Anthony Roach
781         Greg Spencer
782         Christoph Wiedemann
783
784 __COPYRIGHT__