From 72c578fd4b0b4a5a43e18594339ac4ff26c376dc Mon Sep 17 00:00:00 2001
From: Luca Falavigna <dktrkranz@debian.org>
Date: Sat, 2 Jan 2010 20:56:27 +0100
Subject: Imported Upstream version 1.2.0.d20091224

---
 doc/python10/future.xml | 170 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 170 insertions(+)
 create mode 100644 doc/python10/future.xml

(limited to 'doc/python10/future.xml')

diff --git a/doc/python10/future.xml b/doc/python10/future.xml
new file mode 100644
index 0000000..272d508
--- /dev/null
+++ b/doc/python10/future.xml
@@ -0,0 +1,170 @@
+<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>
-- 
cgit v1.2.3