<!DOCTYPE sconsdoc [
<!ENTITY % scons SYSTEM "../scons.mod">
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
There are a number of things we would like to do to continue to
improve &SCons; in the future.
There is a certain amount of overlap between what &SCons; does
to search out and make use of various compilers on a system, and
the impressively complete job that the Distutils do of describing
much the same thing. Collaborating to provide some sort of common
interface between the two tools would benefit both tools.
<title>Additional Builder Support</title>
Adding additional builders would broaden the
potential user base. In rough order of importance:
Given the popularity of Java, support for it would greatly
increase the appeal of &SCons; in the large community of Java
Good support for Java is, however, a tricky
proposition. Because the Java compiler can make decisions
about compiling other files based on what classes it finds
in a file, it behaves "unpredictably" from the point of
view of an outside build tool like &SCons; or &Make;. Some
sort of sophisticated scanning of Java source code to
identify what other classes are likely to be compiled
would be an obvious first step, but notice that here
&SCons; would be scanning the file to find additional
targets to be built. This is the inverse of the sort of
<literal>#include</literal> scanning performed
for C files, in which &SCons; is looking for additional
A number of early adopters
are using &SCons; to
from TeX or DocBook source files.
Built-in support for
various documentation toolchains
would be an obvious boon
for many people.
The reality is that anything that Microsoft does will doubtless
have a wide audience. Turning &SCons;' back on that would be
cutting off its nose to spite its face.
Despite the fact that &SCons; is no longer directly
associated with Software Carpentry, it still shares the
same goal: to make programming easier for more than just
programmers. To that end, good Fortran support would
help a great many physical scientists and other computer
<emphasis>users</emphasis> out there who still rely on Fortran
for a great deal of their work.
The Nodes in an &SCons; dependency graph aren't only restricted to
files. Creating an interface to mSQL or MySQL databases would allow
the possibility of updating external files in response to changes in
database fields, or vice versa. This could be handy, for example,
for generating a cache of static web pages from a database that only
need re-generating when the appropriate database objects change.
&SCons; should work well with as many popular Integrated Development
Environments (IDEs) and tool chains as possible: Komodo, Microsoft
Visual Studio, ClearCase, etc. Suggestions for additional tools are
Because the &SCons; Build Engine can be embedded in any Python
interface, there isn't any technical reason why a &Makefile;
interpreter couldn't be written in Python and use the &SCons; Build
Engine for its dependency analysis.
Proof-of-concept for the idea already exists. Gary Holt's
<literal>make++</literal> (also known as <literal>makepp</literal>)
is a Perl implementation of just such a &Makefile; interpreter. It
could possible serve as a model for a Python version, in much the
same way the &Cons; design served as the prototype for &SCons;.