-SCONS HAS MIGRATED TO GITHUB
-############################
-New repo https://github.com/SConsProject/scons
+SCons - a software construction tool
+####################################
+
+.. image:: https://img.shields.io/badge/IRC-scons-blue.svg
+ :target: http://webchat.freenode.net/?channels=%23scons&uio=d4
+ :alt: IRC
+
+.. image:: https://img.shields.io/sourceforge/dm/scons.svg
+ :target: https://sourceforge.net/projects/scons
+ :alt: Sourceforge Monthly Downloads
+
+.. image:: https://img.shields.io/sourceforge/dt/scons.svg
+ :target: https://sourceforge.net/projects/scons
+ :alt: Sourceforge Total Downloads
+
+Welcome to the SCons development tree. The real purpose of this tree is to
+package SCons for production distribution in a variety of formats, not just to
+hack SCons code.
+
+If all you want to do is install and run SCons, it will be easier for you to
+download and install the scons-{version}.tar.gz or scons-{version}.zip package
+rather than to work with the packaging logic in this tree.
+
+To the extent that this tree is about building SCons packages, the *full*
+development cycle is not just to test the code directly, but to package SCons,
+unpack the package, "install" SCons in a test subdirectory, and then to run
+the tests against the unpacked and installed software. This helps eliminate
+problems caused by, for example, failure to update the list of files to be
+packaged.
+
+For just working on making an individual change to the SCons source, however,
+you don't actually need to build or install SCons; you *can* actually edit and
+execute SCons in-place. See the following sections below for more
+information:
+
+ `Making Changes`_
+ How to edit and execute SCons in-place.
+
+ `Debugging`_
+ Tips for debugging problems in SCons.
+
+ `Testing`_
+ How to use the automated regression tests.
+
+ `Development Workflow`_
+ An example of how to put the edit/execute/test pieces
+ together in a reasonable development workflow.
+
+
+Latest Version
+==============
+
+Before going further, you can check that this package you have is the latest
+version at the SCons download page:
+
+ http://www.scons.org/pages/download.html
+
+
+Execution Requirements
+======================
+
+Running SCons requires Python version 2.7 or later (Python 3 is not
+yet supported). There should be no other dependencies or requirements
+to run SCons.
+
+The default SCons configuration assumes use of the Microsoft Visual C++
+compiler suite on WIN32 systems, and assumes a C compiler named 'cc', a C++
+compiler named 'c++', and a Fortran compiler named 'g77' (such as found in the
+GNU C compiler suite) on any other type of system. You may, of course,
+override these default values by appropriate configuration of Environment
+construction variables.
+
+By default, SCons knows how to search for available programming tools on
+various systems--see the SCons man page for details. You may, of course,
+override the default SCons choices made by appropriate configuration of
+Environment construction variables.
+
+
+Installation Requirements
+=========================
+
+Nothing special.
+
+
+Executing SCons Without Installing
+==================================
+
+You can execute the local SCons directly from the src/ subdirectory by first
+setting the SCONS_LIB_DIR environment variable to the local src/engine
+subdirectory, and then executing the local src/script/scons.py script to
+populate the build/scons/ subdirectory. You would do this as follows on a
+Linux or UNIX system (using sh or a derivative like bash or ksh)::
+
+ $ setenv MYSCONS=`pwd`/src
+ $ setenv SCONS_LIB_DIR=$MYSCONS/engine
+ $ python $MYSCONS/script/scons.py [arguments]
+
+Or on Windows::
+
+ C:\scons>set MYSCONS=%cd%\src
+ C:\scons>set SCONS_LIB_DIR=%MYSCONS%\engine
+ C:\scons>python %MYSCONS%\script\scons.py [arguments]
+
+An alternative approach is to skip the above and use::
+
+ $ python bootstrap.py [arguments]
+
+bootstrap.py keeps the src/ subdirectory free of compiled Python (\*.pyc or
+\*.pyo) files by copying the necessary SCons files to a local bootstrap/
+subdirectory and executing it from there.
+
+You can use the -C option to have SCons change directory to another location
+where you already have a build configuration set up::
+
+ $ python bootstrap.py -C /some/other/location [arguments]
+
+For simplicity in the following examples, we will only show the bootstrap.py
+approach.
+
+
+Installation
+============
+
+ Note: You don't need to build SCons packages or install SCons if you just
+ want to work on developing a patch. See the sections about `Making
+ Changes`_ and `Testing`_ below if you just want to submit a bug fix or
+ some new functionality. See the sections below about `Building Packages`_
+ and `Testing Packages`_ if your enhancement involves changing the way in
+ which SCons is packaged and/or installed on an end-user system.
+
+Assuming your system satisfies the installation requirements in the previous
+section, install SCons from this package by first populating the build/scons/
+subdirectory. (For an easier way to install SCons, without having to populate
+this directory, use the scons-{version}.tar.gz or scons-{version}.zip
+package.)
+
+Populate build/scons/ using a pre-installed SCons
+-------------------------------------------------
+
+If you already have an appropriate version of SCons installed on your system,
+populate the build/scons/ directory by running::
+
+ $ scons build/scons
+
+Populate build/scons/ using the SCons source
+--------------------------------------------
+
+You can also use this version of SCons to populate its own build directory
+by using a supplied bootstrap.py script (see the section above about
+`Executing SCons Without Installing`_)::
+
+ $ python bootstrap.py build/scons
+
+Install the built SCons files
+-----------------------------
+
+Any of the above commands will populate the build/scons/ directory with the
+necessary files and directory structure to use the Python-standard setup
+script as follows on Linux or UNIX::
+
+ # cd build/scons
+ # python setup.py install
+
+Or on Windows::
+
+ C:\scons\>cd build\scons
+ C:\scons\build\scons>python setup.py install
+
+By default, the above commands will do the following:
+
+- Install the version-numbered "scons-3.0.0" and "sconsign-3.0.0" scripts in
+ the default system script directory (/usr/bin or C:\\Python\*\\Scripts, for
+ example). This can be disabled by specifying the "--no-version-script"
+ option on the command line.
+
+- Install scripts named "scons" and "sconsign" scripts in the default system
+ script directory (/usr/bin or C:\\Python\*\\Scripts, for example). This can be
+ disabled by specifying the "--no-scons-script" option on the command line,
+ which is useful if you want to install and experiment with a new version
+ before making it the default on your system.
+
+ On UNIX or Linux systems, you can have the "scons" and "sconsign" scripts be
+ hard links or symbolic links to the "scons-3.0.0" and "sconsign-3.0.0"
+ scripts by specifying the "--hardlink-scons" or "--symlink-scons" options on
+ the command line.
+
+- Install "scons-3.0.0.bat" and "scons.bat" wrapper scripts in the Python
+ prefix directory on Windows (C:\\Python\*, for example). This can be disabled
+ by specifying the "--no-install-bat" option on the command line.
+
+ On UNIX or Linux systems, the "--install-bat" option may be specified to
+ have "scons-3.0.0.bat" and "scons.bat" files installed in the default system
+ script directory, which is useful if you want to install SCons in a shared
+ file system directory that can be used to execute SCons from both UNIX/Linux
+ and Windows systems.
+
+- Install the SCons build engine (a Python module) in an appropriate
+ version-numbered SCons library directory (/usr/lib/scons-3.0.0 or
+ C:\\Python\*\\scons-3.0.0, for example). See below for more options related to
+ installing the build engine library.
+
+- Install the troff-format man pages in an appropriate directory on UNIX or
+ Linux systems (/usr/share/man/man1 or /usr/man/man1, for example). This can
+ be disabled by specifying the "--no-install-man" option on the command line.
+ The man pages can be installed on Windows systems by specifying the
+ "--install-man" option on the command line.
+
+Note that, by default, SCons does not install its build engine library in the
+standard Python library directories. If you want to be able to use the SCons
+library modules (the build engine) in other Python scripts, specify the
+"--standard-lib" option on the command line, as follows::
+
+ # python setup.py install --standard-lib
+
+This will install the build engine in the standard Python library directory
+(/usr/lib/python\*/site-packages or C:\\Python*\\Lib\\site-packages).
+
+Alternatively, you can have SCons install its build engine library in a
+hard-coded standalone library directory, instead of the default
+version-numbered directory, by specifying the "--standalone-lib" option on the
+command line, as follows::
+
+ # python setup.py install --standalone-lib
+
+This is usually not recommended, however.
+
+Note that, to install SCons in any of the above system directories, you should
+have system installation privileges (that is, "root" or "Administrator") when
+running the setup.py script. If you don't have system installation
+privileges, you can use the --prefix option to specify an alternate
+installation location, such as your home directory::
+
+ $ python setup.py install --prefix=$HOME
+
+This will install SCons in the appropriate locations relative to $HOME--that
+is, the scons script itself $HOME/bin and the associated library in
+$HOME/lib/scons, for example.
+
+
+Making Changes
+==============
+
+Because SCons is implemented in a scripting language, you don't need to build
+it in order to make changes and test them.
+
+Virtually all of the SCons functionality exists in the "build engine," the
+src/engine/SCons subdirectory hierarchy that contains all of the modules that
+make up SCons. The src/script/scons.py wrapper script exists mainly to find
+the appropriate build engine library and then execute it.
+
+In order to make your own changes locally and test them by hand, simply edit
+modules in the local src/engine/SCons subdirectory tree and use the local
+bootstrap.py script (see the section above about `Executing SCons Without
+Installing`_)::
+
+ $ python bootstrap.py [arguments]
+
+If you want to be able to just execute your modified version of SCons from the
+command line, you can make it executable and add its directory to your $PATH
+like so::
+
+ $ chmod 755 src/script/scons.py
+ $ export PATH=$PATH:`pwd`/src/script
+
+You should then be able to run this version of SCons by just typing "scons.py"
+at your UNIX or Linux command line.
+
+Note that the regular SCons development process makes heavy use of automated
+testing. See the `Testing`_ and `Development Workflow`_ sections below for more
+information about the automated regression tests and how they can be used in a
+development cycle to validate that your changes don't break existing
+functionality.
+
+
+Debugging
+=========
+
+Python comes with a good interactive debugger. When debugging changes by hand
+(i.e., when not using the automated tests), you can invoke SCons under control
+of the Python debugger by specifying the --debug=pdb option::
+
+ $ scons --debug=pdb [arguments]
+ > /home/knight/SCons/src/engine/SCons/Script/Main.py(927)_main()
+ -> default_warnings = [ SCons.Warnings.CorruptSConsignWarning,
+ (Pdb)
+
+Once in the debugger, you can set breakpoints at lines in files in the build
+engine modules by providing the path name of the file relative to the
+src/engine subdirectory (that is, including the SCons/ as the first directory
+component)::
+
+ (Pdb) b SCons/Tool/msvc.py:158
+
+The debugger also supports single stepping, stepping into functions, printing
+variables, etc.
+
+Trying to debug problems found by running the automated tests (see the
+`Testing`_ section, below) is more difficult, because the test automation
+harness re-invokes SCons and captures output. Consequently, there isn't an
+easy way to invoke the Python debugger in a useful way on any particular SCons
+call within a test script.
+
+The most effective technique for debugging problems that occur during an
+automated test is to use the good old tried-and-true technique of adding
+statements to print tracing information. But note that you can't just use
+"print" statement, or even "sys.stdout.write()" because those change the
+SCons output, and the automated tests usually look for matches of specific
+output strings to decide if a given SCons invocations passes the test.
+
+To deal with this, SCons supports a Trace() function that (by default) will
+print messages to your console screen ("/dev/tty" on UNIX or Linux, "con" on
+Windows). By adding Trace() calls to the SCons source code::
+
+ def sample_method(self, value):
+ from SCons.Debug import Trace
+ Trace('called sample_method(%s, %s)\n' % (self, value))
+
+You can then run automated tests that print any arbitrary information you wish
+about what's going on inside SCons, without interfering with the test
+automation.
+
+The Trace() function can also redirect its output to a file, rather than the
+screen::
+
+ def sample_method(self, value):
+ from SCons.Debug import Trace
+ Trace('called sample_method(%s, %s)\n' % (self, value),
+ file='trace.out')
+
+Where the Trace() function sends its output is stateful: once you use the
+"file=" argument, all subsequent calls to Trace() send their output to the
+same file, until another call with a "file=" argument is reached.
+
+
+Testing
+=======
+
+Tests are run by the runtest.py script in this directory.
+
+There are two types of tests in this package:
+
+1. Unit tests for individual SCons modules live underneath the src/engine/
+ subdirectory and are the same base name as the module with "Tests.py"
+ appended--for example, the unit test for the Builder.py module is the
+ BuilderTests.py script.
+
+2. End-to-end tests of SCons live in the test/ subdirectory.
+
+You may specifically list one or more tests to be run::
+
+ $ python runtest.py src/engine/SCons/BuilderTests.py
+
+ $ python runtest.py test/option-j.py test/Program.py
+
+You also use the -f option to execute just the tests listed in a specified
+text file::
+
+ $ cat testlist.txt
+ test/option-j.py
+ test/Program.py
+ $ python runtest.py -f testlist.txt
+
+One test must be listed per line, and any lines that begin with '#' will be
+ignored (allowing you, for example, to comment out tests that are currently
+passing and then uncomment all of the tests in the file for a final validation
+run).
+
+The runtest.py script also takes a -a option that searches the tree for all of
+the tests and runs them::
+
+ $ python runtest.py -a
+
+If more than one test is run, the runtest.py script prints a summary of how
+many tests passed, failed, or yielded no result, and lists any unsuccessful
+tests.
+
+The above invocations all test directly the files underneath the src/
+subdirectory, and do not require that a build be performed first. The
+runtest.py script supports additional options to run tests against unpacked
+packages in the build/test-\*/ subdirectories. See the `Testing Packages`_
+section below.
+
+
+Development Workflow
+====================
+
+ Caveat: The point of this section isn't to describe one dogmatic workflow.
+ Just running the test suite can be time-consuming, and getting a patch to
+ pass all of the tests can be more so. If you're genuinely blocked, it may
+ make more sense to submit a patch with a note about which tests still
+ fail, and how. Someone else may be able to take your "initial draft" and
+ figure out how to improve it to fix the rest of the tests. So there's
+ plenty of room for use of good judgement.
+
+The various techniques described in the above sections can be combined to
+create simple and effective workflows that allow you to validate that patches
+you submit to SCons don't break existing functionality and have adequate
+testing, thereby increasing the speed with which they can be integrated.
+
+For example, suppose your project's SCons configuration is blocked by an SCons
+bug, and you decide you want to fix it and submit the patch. Here's one
+possible way to go about doing that (using UNIX/Linux as the development
+platform, Windows users can translate as appropriate)):
+
+- Change to the top of your checked-out SCons tree.
+
+- Confirm that the bug still exists in this version of SCons by using the -C
+ option to run the broken build::
+
+ $ python bootstrap.py -C /home/me/broken_project .
+
+- Fix the bug in SCons by editing appropriate module files underneath
+ src/engine/SCons.
+
+- Confirm that you've fixed the bug affecting your project::
+
+ $ python bootstrap.py -C /home/me/broken_project .
+
+- Test to see if your fix had any unintended side effects that break existing
+ functionality::
+
+ $ python runtest.py -a -o test.log
+
+ Be patient, there are more than 700 test scripts in the whole suite. If you
+ are on UNIX/Linux, you can use::
+
+ $ python runtest.py -a | tee test.log
+
+ instead so you can monitor progress from your terminal.
+
+ If any test scripts fail, they will be listed in a summary at the end of the
+ log file. Some test scripts may also report NO RESULT because (for example)
+ your local system is the wrong type or doesn't have some installed utilities
+ necessary to run the script. In general, you can ignore the NO RESULT list.
+
+- Cut-and-paste the list of failed tests into a file::
+
+ $ cat > failed.txt
+ test/failed-test-1.py
+ test/failed-test-2.py
+ test/failed-test-3.py
+ ^D
+ $
+
+- Now debug the test failures and fix them, either by changing SCons, or by
+ making necessary changes to the tests (if, for example, you have a strong
+ reason to change functionality, or if you find that the bug really is in the
+ test script itself). After each change, use the runtest.py -f option to
+ examine the effects of the change on the subset of tests that originally
+ failed::
+
+ $ [edit]
+ $ python runtest.py -f failed.txt
+
+ Repeat this until all of the tests that originally failed now pass.
+
+- Now you need to go back and validate that any changes you made while getting
+ the tests to pass didn't break the fix you originally put in, and didn't
+ introduce any *additional* unintended side effects that broke other tests::
+
+ $ python bootstrap.py -C /home/me/broken_project .
+ $ python runtest.py -a -o test.log
+
+ If you find any newly-broken tests, add them to your "failed.txt" file and
+ go back to the previous step.
+
+Of course, the above is only one suggested workflow. In practice, there is a
+lot of room for judgment and experience to make things go quicker. For
+example, if you're making a change to just the Java support, you might start
+looking for regressions by just running the test/Java/\*.py tests instead of
+running all of "runtest.py -a".
+
+
+Building Packages
+=================
+
+We use SCons (version 3.0.0 or later) to build its own packages. If you
+already have an appropriate version of SCons installed on your system, you can
+build everything by simply running it::
+
+ $ scons
+
+If you don't have SCons already installed on your
+system, you can use the supplied bootstrap.py script (see the section above
+about `Executing SCons Without Installing`_)::
+
+ $ python bootstrap.py build/scons
+
+Depending on the utilities installed on your system, any or all of the
+following packages will be built::
+
+ build/dist/scons-3.0.0-1.noarch.rpm
+ build/dist/scons-3.0.0-1.src.rpm
+ build/dist/scons-3.0.0.linux-i686.tar.gz
+ build/dist/scons-3.0.0.tar.gz
+ build/dist/scons-3.0.0.win32.exe
+ build/dist/scons-3.0.0.zip
+ build/dist/scons-doc-3.0.0.tar.gz
+ build/dist/scons-local-3.0.0.tar.gz
+ build/dist/scons-local-3.0.0.zip
+ build/dist/scons-src-3.0.0.tar.gz
+ build/dist/scons-src-3.0.0.zip
+ build/dist/scons_3.0.0-1_all.deb
+
+The SConstruct file is supposed to be smart enough to avoid trying to build
+packages for which you don't have the proper utilities installed. For
+example, if you don't have Debian packaging tools installed, it should just
+not build the .deb package, not fail the build.
+
+If you receive a build error, please report it to the scons-devel mailing list
+and open a bug report on the SCons bug tracker.
+
+Note that in addition to creating the above packages, the default build will
+also unpack one or more of the packages for testing.
+
+
+Testing Packages
+================
+
+A full build will unpack and/or install any .deb, .rpm., .local.tar.gz,
+.local.zip, .src.tar.gz, .src.zip, .tar.gz, and .zip packages into separate
+build/test-\*/ subdirectories. (Of course, if a package was not built on your
+system, it should not try to install it.) The runtest.py script supports a -p
+option that will run the specified tests (individually or collectively via
+the -a option) against the unpacked build/test-/\* subdirectory::
+
+ $ python runtest.py -p deb
+
+ $ python runtest.py -p rpm
+
+ $ python runtest.py -p local-tar-gz
+
+ $ python runtest.py -p local-zip
+
+ $ python runtest.py -p src-tar-gz
+
+ $ python runtest.py -p src-zip
+
+ $ python runtest.py -p tar-gz
+
+ $ python runtest.py -p zip
+
+(The canonical invocation is to also use the runtest.py -a option so that all
+tests are run against the specified package.)
+
+
+Contents of this Package
+========================
+
+Not guaranteed to be up-to-date (but better than nothing):
+
+bench/
+ A subdirectory for benchmarking scripts, used to perform timing tests
+ to decide what specific idioms are most efficient for various parts of
+ the code base. We check these in so they're available in case we have
+ to revisit any of these decisions in the future.
+
+bin/
+ Miscellaneous utilities used in SCons development. Right now,
+ some of the stuff here includes:
+
+ - a script that runs pychecker on our source tree;
+
+ - a script that counts source and test files and numbers of lines in each;
+
+ - a prototype script for capturing sample SCons output in xml files;
+
+ - a script that can profile and time a packaging build of SCons itself;
+
+ - a copy of xml_export, which can retrieve project data from SourceForge;
+ and
+
+ - scripts and a Python module for translating the SCons home-brew XML
+ documentation tags into DocBook and man page format
+
+
+bootstrap.py
+ Build script for running SCons from the current source code checkout. This
+ copies SCons files to bootstrap/ subdirectory, and then executes SCons
+ with the supplied command-line arguments.
+
+build/
+ This doesn't exist yet if you're looking at a vanilla source tree. This
+ is generated as part of our build process, and it's where, believe it or
+ not, we *build* everything.
+
+debian/
+ Files needed to construct a Debian package. The contents of this directory
+ are dictated by the Debian Policy Manual
+ (http://www.debian.org/doc/debian-policy). The package will not be
+ accepted into the Debian distribution unless the contents of this
+ directory satisfy the relevant Debian policies.
+
+doc/
+ SCons documentation. A variety of things here, in various stages of
+ (in)completeness.
+
+gentoo/
+ Stuff to generate files for Gentoo Linux.
+
+HOWTO/
+ Documentation of SCons administrative procedures (making a change,
+ releasing a new version). Maybe other administrative stuff in the future.
+
+LICENSE
+ A copy of the copyright and terms under which SCons is distributed (the
+ Open Source Initiative-approved MIT license).
+
+LICENSE-local
+ A copy of the copyright and terms under which SCons is distributed for
+ inclusion in the scons-local-{version} packages. This is the same as
+ LICENSE with a preamble that specifies the licensing terms are for SCons
+ itself, not any other package that includes SCons.
+
+QMTest/
+ The Python modules we use for testing, some generic modules originating
+ elsewhere and some specific to SCons.
+
+README.rst
+ What you're looking at right now.
+
+README-local
+ A README file for inclusion in the scons-local-{version} packages.
+ Similar to this file, but stripped down and modified for people looking at
+ including SCons in their shipped software.
+
+rpm/
+ The .spec file for building our RPM packages.
+
+runtest.py
+ Script for running SCons tests. By default, this will run a test against
+ the code in the local src/ tree, so you don't have to do a build before
+ testing your changes.
+
+SConstruct
+ The file describing to SCons how to build the SCons distribution.
+
+ (It has been pointed out that it's hard to find the SCons API in this
+ SConstruct file, and that it looks a lot more like a pure Python script
+ than a build configuration file. That's mainly because all of the magick
+ we have to perform to deal with all of the different packaging formats
+ requires a lot of pure Python manipulation. In other words, don't look at
+ this file for an example of how easy it is to use SCons to build "normal"
+ software.)
+
+src/
+ Where the actual source code is kept, of course.
+
+test/
+ End-to-end tests of the SCons utility itself. These are separate from the
+ individual module unit tests, which live side-by-side with the modules
+ under src/.
+
+
+Documentation
+=============
+
+See the src/RELEASE.txt file for notes about this specific release, including
+known problems. See the src/CHANGES.txt file for a list of changes since the
+previous release.
+
+The doc/man/scons.1 man page is included in this package, and contains a
+section of small examples for getting started using SCons.
+
+Additional documentation for SCons is available at:
+
+ http://www.scons.org/documentation.html
+
+
+Licensing
+=========
+
+SCons is distributed under the MIT license, a full copy of which is available
+in the LICENSE file.
+
+
+Reporting Bugs
+==============
+
+Please report bugs by following the detailed instructions on our Bug
+Submission page:
+
+ http://scons.tigris.org/bug-submission.html
+
+You can also send mail to the SCons developers' mailing list:
+
+ scons-dev@scons.org
+
+But even if you send email to the mailing list please make sure that you ALSO
+submit a bug report to the project page bug tracker, because bug reports in
+email often get overlooked in the general flood of messages.
+
+
+Mailing Lists
+=============
+
+An active mailing list for developers of SCons is available. You may
+send questions or comments to the list at:
+
+ scons-dev@scons.org
+
+You may subscribe to the developer's mailing list using form on this page:
+
+ http://two.pairlist.net/mailman/listinfo/scons-dev
+
+Subscription to the developer's mailing list is by approval. In practice, no
+one is refused list membership, but we reserve the right to limit membership
+in the future and/or weed out lurkers.
+
+There is also a low-volume mailing list available for announcements about
+SCons. Subscribe by sending email to:
+
+ announce-subscribe@scons.tigris.org
+
+There are other mailing lists available for SCons users, for notification of
+SCons code changes, and for notification of updated bug reports and project
+documents. Please see our mailing lists page for details.
+
+
+Donations
+=========
+
+If you find SCons helpful, please consider making a donation (of cash,
+software, or hardware) to support continued work on the project. Information
+is available at:
+
+ http://www.scons.org/donate.html
+
+
+For More Information
+====================
+
+Check the SCons web site at:
+
+ http://www.scons.org/
+
+
+Author Info
+===========
+
+SCons was originally written by Steven Knight, knight at baldmt dot com.
+Since around 2010 it has been maintained by the SCons
+development team, co-managed by Bill Deegan and Gary Oberbrunner, with
+many contributors, including but not at all limited to:
+
+- Chad Austin
+- Dirk Baechle
+- Charles Crain
+- William Deegan
+- Steve Leblanc
+- Rob Managan
+- Greg Noel
+- Gary Oberbrunner
+- Anthony Roach
+- Greg Spencer
+- Tom Tanner
+- Anatoly Techtonik
+- Christoph Wiedemann
+- Russel Winder
+
+\... and many others.
Copyright (c) 2001 - 2017 The SCons Foundation
projects / platform / upstream / scons.git / commitdiff