diff options
Diffstat (limited to 'doc/python10/future.sgml')
| -rw-r--r-- | doc/python10/future.sgml | 170 |
1 files changed, 0 insertions, 170 deletions
diff --git a/doc/python10/future.sgml b/doc/python10/future.sgml deleted file mode 100644 index 272d508..0000000 --- a/doc/python10/future.sgml +++ /dev/null @@ -1,170 +0,0 @@ -<para> - - There are a number of things we would like to do to continue to - improve &SCons; in the future. - -</para> - -<section> - <title>Distutils Cooperation</title> - - <para> - - 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. - - </para> - -</section> - -<section> - <title>Additional Builder Support</title> - - <para> - - Adding additional builders would broaden the - potential user base. In rough order of importance: - - </para> - - <variablelist> - - <varlistentry> - <term>Java</term> - <listitem> - <para> - - Given the popularity of Java, support for it would greatly - increase the appeal of &SCons; in the large community of Java - users. - - </para> - - <para> - - 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 - <emphasis>dependencies</emphasis>. - - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Documentation toolchains</term> - <listitem> - <para> - - 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. - - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>C#</term> - <listitem> - <para> - - 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. - - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Fortran</term> - <listitem> - <para> - - 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. - - </para> - </listitem> - </varlistentry> - - </variablelist> - -</section> - -<section> - <title>Database Interface</title> - - <para> - - 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. - - </para> - -</section> - -<section> - <title>Tool Integration</title> - - <para> - - &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. - - </para> - -</section> - -<section> - <title>Makefile Interface</title> - - <para> - - 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. - - </para> - - <para> - - 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;. - - </para> - -</section> |