Fix over-zealous common prefix matching when generating Visual Studio project files...

[scons.git] / README

# __COPYRIGHT__

                 SCons - a software construction tool

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.

To that extent, the normal 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.

Note that if all you want to do is install and run SCons, it
will probably 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.


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/download.html


EXECUTION REQUIREMENTS
======================

Running SCons requires Python version 1.5.2 or later.  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
=========================

Building and installing SCons from this package requires the Python
distutils package.  The distutils package was not shipped as a standard
part of Python until Python version 1.6, so if your system is running
Python 1.5.2, you may not have distutils installed.  If you are running
Python version 1.6 or later, you should be fine.

NOTE TO RED HAT USERS:  Red Hat shipped Python 1.5.2 as the default all
the way up to Red Hat Linux 7.3, so you probably do *not* have distutils
installed, unless you have already done so manually or are running Red
Hat 8.0 or later.

In this case, your options are:

    --  (Optional.)  Install from a pre-packaged SCons package that
        does not require distutils:

            Red Hat Linux       scons-0.96.noarch.rpm

            Debian GNU/Linux    scons_0.96_all.deb
                                (or use apt-get)

            Windows             scons-0.96.win32.exe

    --  (Recommended.)  Download the latest distutils package from the
        following URL:

            http://www.python.org/sigs/distutils-sig/download.html

        Install the distutils according to the instructions on the page.
        You can then proceed to the next section to install SCons from
        this package.


INSTALLATION
============

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.)

If you already have an appropriate version of SCons installed on your
system, populate the build/scons/ directory by running:

        $ scons build/scons

If you don't have SCons version 0.96 or later already installed on your
system, you can use SCons itself to populate the build/scons/ directory
with a little more typing.  You must first set the SCONS_LIB_DIR
environment variable to the local src/engine subdirectory, and then
execute 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):

        $ export SCONS_LIB_DIR=`pwd`/src/engine
        $ python src/script/scons.py build/scons

Or as follows on Windows:
        
        C:\scons\>set SCONS_LIB_DIR=%cd%\src\engine
        C:\scons\>python src/script/scons.py build/scons

Either command 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

And 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-0.96" and "sconsign-0.96"
        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-0.96" and "sconsign-0.96" scripts
        by specifying the "--hardlink-scons" or "--symlink-scons"
        options on the command line.

    --  Install "scons-0.96.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.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 or C:\Python*\scons-0.96, 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.


TESTING
=======

Tests are run by the runtest.py script in this directory.

There are two types of tests in this package:

    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.

    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

Alternatively, the runtest.py script 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.


BUILDING PACKAGES
=================

We use SCons (version 0.96 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 version 0.96 or later already installed on your
system, you can build this version of SCons with itself 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
        $ python src/script/scons.py

On Windows:
        
        C:\scons\>set SCONS_LIB_DIR=%cd%\src\engine
        C:\scons\>python src/script/scons.py

Depending on the utilities installed on your system, any or all of the
following packages will be built:

        build/dist/scons-0.96-1.noarch.rpm
        build/dist/scons-0.96-1.src.rpm
        build/dist/scons-0.96.linux-i686.tar.gz
        build/dist/scons-0.96.tar.gz
        build/dist/scons-0.96.win32.exe
        build/dist/scons-0.96.zip
        build/dist/scons-doc-0.96.tar.gz
        build/dist/scons-local-0.96.tar.gz
        build/dist/scons-local-0.96.zip
        build/dist/scons-src-0.96.tar.gz
        build/dist/scons-src-0.96.zip
        build/dist/scons_0.96-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 copy of the script we use to translate an Aegis change
                into a CVS checkin
            --  a script that runs pychecker on our source tree
            --  a script that counts source and test files and numbers
                of lines in each
            --  a script for synchronizing the Aegis tree to SourceForge
            --  a prototype script for capturing sample SCons output
                in sgml 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

bootstrap.py
        A build script for use with Aegis.  This collects a current copy
        of SCons from the Aegis baseline directories in a 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.

config
        The Aegis configuration, governing much of how we use Aegis to
        build, test, control source, etc.

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.

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.

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.

README
        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.  Aegis uses
        it with an option that requires that you've done a build
        (aeb) before running tests.

SConstruct
        The "Makefile" for 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.

template/
        Template files, used by Aegis to give you a head start when you
        aenf or aent a new file.

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/doc.html


LICENSING
=========

SCons is distributed under the MIT license, a full copy of which is
available in the LICENSE file. The MIT license is an approved Open
Source license, which means:

        This software is OSI Certified Open Source Software.  OSI
        Certified is a certification mark of the Open Source Initiative.

More information about OSI certifications and Open Source software is
available at:

        http://www.opensource.org/


REPORTING BUGS
==============

Please report bugs by following the "Tracker - Bugs" link on the SCons
project page and filling out the form:

        http://sourceforge.net/projects/scons/

You can also send mail to the SCons developers mailing list:

        scons-devel@lists.sourceforge.net

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.


MAILING LISTS
=============

An active mailing list for developers of SCons is available.  You may
send questions or comments to the list at:

        dev@scons.tigris.org

You may request a subscription to the developer's mailing list by sending
email to:

        dev-subscribe@scons.tigris.org

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
===========

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