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 (enforced by Aegis) is not 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.
+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
-- (Optional.) Install from a pre-packaged SCons package that
does not require distutils:
- Red Hat Linux scons-0.96.93.noarch.rpm
+ Red Hat Linux scons-1.2.0.noarch.rpm
- Debian GNU/Linux scons_0.96.93_all.deb
- (or use apt-get)
+ Debian GNU/Linux use apt-get to get the official package
- Windows scons-0.96.93.win32.exe
+ Windows scons-1.2.0.win32.exe
-- (Recommended.) Download the latest distutils package from the
following URL:
You can also 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 execute the local src/script/scons.py
+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):
By default, the above commands will do the following:
- -- Install the version-numbered "scons-0.96.93" and "sconsign-0.96.93"
+ -- Install the version-numbered "scons-1.2.0" and "sconsign-1.2.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
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-0.96.93" and "sconsign-0.96.93" scripts
- by specifying the "--hardlink-scons" or "--symlink-scons"
- options on the command line.
+ making it the default on your system.
- -- Install "scons-0.96.93.bat" and "scons.bat" wrapper scripts in the
+ On UNIX or Linux systems, you can have the "scons" and "sconsign"
+ scripts be hard links or symbolic links to the "scons-1.2.0" and
+ "sconsign-1.2.0" scripts by specifying the "--hardlink-scons" or
+ "--symlink-scons" options on the command line.
+
+ -- Install "scons-1.2.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-0.96.93.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.
+ on the command line.
+
+ On UNIX or Linux systems, the "--install-bat" option may be
+ specified to have "scons-1.2.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-0.96.93 or C:\Python*\scons-0.96.93, for example).
+ (/usr/lib/scons-1.2.0 or C:\Python*\scons-1.2.0, for example).
See below for more options related to installing the build
engine library.
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 change locally and test them by hand, simply
-edit modules in the local src/engine/SCons subdirectory tree and
-either use the local bootstrap.py script:
+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 either
+use the local bootstrap.py script:
$ python bootstrap.py [arguments]
set up environment variables to do this on a UNIX or Linux system:
$ setenv MYSCONS=`pwd`/src
- $ setenv SCONS_LIB_DIR=$MYSCONS
+ $ 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%
+ C:\scons>set SCONS_LIB_DIR=%MYSCONS%\engine
C:\scons>python %MYSCONS%\script\scons.py [arguments]
You can use the -C option to have SCons change directory to another
"con" on Windows). By adding Trace() calls to the SCons source code:
def sample_method(self, value):
- fromn SCons.Debug import Trace
+ 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
the screen:
def sample_method(self, value):
- fromn SCons.Debug import Trace
+ from SCons.Debug import Trace
Trace('called sample_method(%s, %s)\n' % (self, value),
file='trace.out')
$ python runtest.py -a
- Be patient, there are more than 500 test scripts in the
+ Be patient, there are more than 700 test scripts in the
whole suite.
If any test scripts fail, they will be listed in a summary at
^D
$
- -- Now debug the test failures and fix them, either by changing
+ -- 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).
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, or introduce any *additional* unintended side
- effects that broke other tests:
+ -- 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 script/scons.py -C /home/me/broken_project .
$ python runtest.py -a
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's
-a lot of room for judgment and experience to make things go quicker.
+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".
$ scons
If you don't have SCons version 0.96.93 later already installed on your
-system, you can build this version of SCons with itself with a little more
+system, you can use the supplied bootstrap.py script:
+
+ $ python bootstrap.py build/scons
+
+The 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 also build this version of SCons by hand with a little more
typing. On UNIX or Linux (using sh or a derivative like bash or ksh):
$ export SCONS_LIB_DIR=`pwd`/src/engine
Depending on the utilities installed on your system, any or all of the
following packages will be built:
- build/dist/scons-0.96.93-1.noarch.rpm
- build/dist/scons-0.96.93-1.src.rpm
- build/dist/scons-0.96.93.linux-i686.tar.gz
- build/dist/scons-0.96.93.tar.gz
- build/dist/scons-0.96.93.win32.exe
- build/dist/scons-0.96.93.zip
- build/dist/scons-doc-0.96.93.tar.gz
- build/dist/scons-local-0.96.93.tar.gz
- build/dist/scons-local-0.96.93.zip
- build/dist/scons-src-0.96.93.tar.gz
- build/dist/scons-src-0.96.93.zip
- build/dist/scons_0.96.93-1_all.deb
+ build/dist/scons-1.2.0-1.noarch.rpm
+ build/dist/scons-1.2.0-1.src.rpm
+ build/dist/scons-1.2.0.linux-i686.tar.gz
+ build/dist/scons-1.2.0.tar.gz
+ build/dist/scons-1.2.0.win32.exe
+ build/dist/scons-1.2.0.zip
+ build/dist/scons-doc-1.2.0.tar.gz
+ build/dist/scons-local-1.2.0.tar.gz
+ build/dist/scons-local-1.2.0.zip
+ build/dist/scons-src-1.2.0.tar.gz
+ build/dist/scons-src-1.2.0.zip
+ build/dist/scons_1.2.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.
of lines in each
-- a script for synchronizing the Aegis tree to SourceForge
-- a prototype script for capturing sample SCons output
- in sgml files
+ 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
+ -- scripts and a Python module for translating the SCons
+ home-brew XML documentation tags into DocBook and
+ man page format
bootstrap.py
A build script for use with Aegis. This collects a current copy
SCons documentation. A variety of things here, in various
stages of (in)completeness.
-etc/
- A subdirectory for miscellaneous things that we need. Right
- now, it has copies of Python modules that we use for testing,
- and which we don't want to force people to have to install on
- their own just to help out with SCons development.
-
gentoo/
Stuff to generate files for Gentoo Linux.
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
What you're looking at right now.
REPORTING BUGS
==============
-Please report bugs by following the "Tracker - Bugs" link on the SCons
-project page and filling out the form:
+Please report bugs by following the detailed instructions on our Bug
+Submission page:
- http://sourceforge.net/projects/scons/
+ http://scons.tigris.org/bug-submission.html
-You can also send mail to the SCons developers mailing list:
+You can also send mail to the SCons developers' mailing list:
- scons-devel@lists.sourceforge.net
+ dev@scons.tigris.org
-But please make sure that you also submit a bug report to the project
-page bug tracker, because bug reports in email can sometimes get lost
-in the general flood of messages.
+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
With plenty of help from the SCons Development team:
Chad Austin
Charles Crain
+ Bill Deegan
Steve Leblanc
+ Greg Noel
Gary Oberbrunner
Anthony Roach
Greg Spencer
projects / scons.git / blobdiff