| SCons Design and Implementation | ||
|---|---|---|
| <<< Previous | Next >>> | |
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:
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.
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.
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 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.
| <<< Previous | Home | Next >>> |
| Development Process | Summary |