%scons; ]>

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.

Adding additional builders would broaden the potential user base. In rough order of importance: Java Given the popularity of Java, support for it would greatly increase the appeal of &SCons; in the large community of Java users. 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 #include scanning performed for C files, in which &SCons; is looking for additional dependencies. Documentation toolchains A number of early adopters are using &SCons; to build documents from TeX or DocBook source files. Built-in support for various documentation toolchains would be an obvious boon for many people. C# 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. Fortran 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 users 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 welcome.

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 make++ (also known as makepp) 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;.