As a next-generation build tool, SCons should fundamentally improve on its predecessors. Rather than simply being driven by trying to not be like previous tools, SCons aims to satisfy the following goals:
The SCons design emphasizes an implementable feature set that lets users get practical, useful work done. SCons is helped in this regard by its roots in Cons, which has had its feature set honed by several years of input from a dedicated band of users.
SCons is intended as a portable build tool,
able to handle software construction tasks
on a variety of operating systems.
It should be possible (although not mandatory)
to use SCons so that the same configuration file
builds the same software correctly on,
for example, both Linux and Windows NT.
Consequently, SCons should hide from users
such as filename extensions
Novice users should be able to grasp quickly the rudiments of using SCons to build their software. This extends to installing SCons, too. Installation should be painless, and the installed SCons should work "out of the box" to build most software.
This goal should be kept in mind during implementation, when there is always a tendency to try to optimize too early. Speed is nice, but not as important as clarity and ease of use.
SCons should also provide a rich enough set of features to accommodate building more complicated software projects. However, the features required for building complicated software projects should not get in the way of novice users. (See the previous goal.) In other words, complexity should be available when it's needed but not required to get work done. Practically, this implies that SCons shouldn't be dumbed down to the point it excludes complicated software builds.
As a key element in balancing the conflicting
SCons should provide mechanisms to
allow SCons users to share build rules,
dependency scanners, and other objects and recipes
for constructing software.
A good sharing mechanism should support
the model wherein most developers on a project
use rules and templates
that are created
and maintained by a local integrator or build-master,
SCons should provide mechanisms for easily extending its capabilities, including building new types of files, adding new types of dependency scanning, being able to accomodate dependencies between objects other than files, etc.
In addition to providing a useful command-line interface, SCons should provide the right architectural framework for embedding its dependency management in other interfaces. SCons would help strengthen other GUIs or IDEs and the additional requirements of the other interfaces would help broaden and solidify the core SCons dependency management.