doc/python10/future.sgml

   1 <para>
   2
   3   There are a number of things we would like to do to continue to
   4   improve &SCons; in the future.
   5
   6 </para>
   7
   8 <section>
   9   <title>Distutils Cooperation</title>
  10
  11   <para>
  12
  13     There is a certain amount of overlap between what &SCons; does
  14     to search out and make use of various compilers on a system, and
  15     the impressively complete job that the Distutils do of describing
  16     much the same thing. Collaborating to provide some sort of common
  17     interface between the two tools would benefit both tools.
  18
  19   </para>
  20
  21 </section>
  22
  23 <section>
  24   <title>Additional Builder Support</title>
  25
  26   <para>
  27
  28     Adding additional builders would broaden the
  29     potential user base. In rough order of importance:
  30
  31   </para>
  32
  33   <variablelist>
  34
  35     <varlistentry>
  36       <term>Java</term>
  37       <listitem>
  38         <para>
  39
  40           Given the popularity of Java, support for it would greatly
  41           increase the appeal of &SCons; in the large community of Java
  42           users.
  43
  44         </para>
  45
  46         <para>
  47
  48           Good support for Java is, however, a tricky
  49           proposition. Because the Java compiler can make decisions
  50           about compiling other files based on what classes it finds
  51           in a file, it behaves "unpredictably" from the point of
  52           view of an outside build tool like &SCons; or &Make;. Some
  53           sort of sophisticated scanning of Java source code to
  54           identify what other classes are likely to be compiled
  55           would be an obvious first step, but notice that here
  56           &SCons; would be scanning the file to find additional
  57           targets to be built. This is the inverse of the sort of
  58           <literal>#include</literal> scanning performed
  59           for C files, in which &SCons; is looking for additional
  60           <emphasis>dependencies</emphasis>.
  61
  62         </para>
  63       </listitem>
  64     </varlistentry>
  65
  66     <varlistentry>
  67       <term>Documentation toolchains</term>
  68       <listitem>
  69         <para>
  70
  71           A number of early adopters
  72           are using &SCons; to
  73           build documents
  74           from TeX or DocBook source files.
  75           Built-in support for
  76           various documentation toolchains
  77           would be an obvious boon
  78           for many people.
  79
  80         </para>
  81       </listitem>
  82     </varlistentry>
  83
  84     <varlistentry>
  85       <term>C#</term>
  86       <listitem>
  87         <para>
  88
  89           The reality is that anything that Microsoft does will doubtless
  90           have a wide audience. Turning &SCons;' back on that would be
  91           cutting off its nose to spite its face.
  92
  93         </para>
  94       </listitem>
  95     </varlistentry>
  96
  97     <varlistentry>
  98       <term>Fortran</term>
  99       <listitem>
 100         <para>
 101
 102           Despite the fact that &SCons; is no longer directly
 103           associated with Software Carpentry, it still shares the
 104           same goal: to make programming easier for more than just
 105           programmers. To that end, good Fortran support would
 106           help a great many physical scientists and other computer
 107           <emphasis>users</emphasis> out there who still rely on Fortran
 108           for a great deal of their work.
 109
 110         </para>
 111       </listitem>
 112     </varlistentry>
 113
 114   </variablelist>
 115
 116 </section>
 117
 118 <section>
 119   <title>Database Interface</title>
 120
 121   <para>
 122
 123     The Nodes in an &SCons; dependency graph aren't only restricted to
 124     files. Creating an interface to mSQL or MySQL databases would allow
 125     the possibility of updating external files in response to changes in
 126     database fields, or vice versa. This could be handy, for example,
 127     for generating a cache of static web pages from a database that only
 128     need re-generating when the appropriate database objects change.
 129
 130   </para>
 131
 132 </section>
 133
 134 <section>
 135   <title>Tool Integration</title>
 136
 137   <para>
 138
 139     &SCons; should work well with as many popular Integrated Development
 140     Environments (IDEs) and tool chains as possible: Komodo, Microsoft
 141     Visual Studio, ClearCase, etc. Suggestions for additional tools are
 142     welcome.
 143
 144   </para>
 145
 146 </section>
 147
 148 <section>
 149   <title>Makefile Interface</title>
 150
 151   <para>
 152
 153     Because the &SCons; Build Engine can be embedded in any Python
 154     interface, there isn't any technical reason why a &Makefile;
 155     interpreter couldn't be written in Python and use the &SCons; Build
 156     Engine for its dependency analysis.
 157
 158   </para>
 159
 160   <para>
 161
 162     Proof-of-concept for the idea already exists. Gary Holt's
 163     <literal>make++</literal> (also known as <literal>makepp</literal>)
 164     is a Perl implementation of just such a &Makefile; interpreter. It
 165     could possible serve as a model for a Python version, in much the
 166     same way the &Cons; design served as the prototype for &SCons;.
 167
 168   </para>
 169
 170 </section>