SCons is a next-generation, cross-platform, build tool. Think of SCons as an improved substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache.

Unlike build tools that invent their own mini-language or wedge a scripting language onto some other configuration file syntax, SCons configuration files are actually Python scripts. The ability to script your build gives you a tremendous amount of flexibility to solve complicated build problems in surprisingly small amounts of maintainable code.

In short, SCons is an easier, more flexible and more reliable way to build software.

-----

Until your project is approved, only you can view it and work on it.

• This index.html will be used if and only if you have the "Use Project Home Page" option checked on the "Adminster Project" page (click the "Admin" tab).
• To edit this file, check out your project via CVS and edit www/index.html.
• You can 'cvs add' and commit other files under the project's "www" directory and they will published to your project web site.
• Also, consider starting a thread in the "dev" mailing list to get thes discussion started. A good one is an "introduction" thread where people post messages about themselves and their interest in the project.
• You can add a "Highlights:" line to the top of all web pages by adding a file www/project_highlights.html

Mission

The goal of The SCons Project is to become the premiere build tool for cross-platform, multi-language software projects by offering unparalleled reliability, flexibility and ease of use.

What is the scope of this project?

For example:

• Develop just enough functionality to scratch a particular itch
• Build a tool just like XYZ, but less broken
• Build the best XYZ-tool ever!

What are high-level features you are sure to build?

• What would you write on a billboard about your project? Users might only look for a few seconds.
• Use the issue tracker to track features and enhancement requests. It is not just for bugs, pre-populate it with feature descriptions so that potential contributors know what you would like them to work on.

What are the high-level assumptions or ground rules for the project?

For example:

• we will use programming language X on operating system Y for now.
• We will, or will not, consider certain functional areas like internationalization, high security, concurrency, etc. The list of functional areas will depend on what you are trying to do.
• Try to keep this part short.

Related resources

• Link to other stuff that you know about. It will help you research requirements and provide a useful resource to potential contributors.
• Why reinvent the wheel? What is better about this wheel? Is there any existing project that you can partner with or reuse?
• Where would you go to try to find potential contibutors?