doc/python10/future.xml

   1 <?xml version='1.0'?>
   2 <!DOCTYPE sconsdoc [
   3     <!ENTITY % scons SYSTEM "../scons.mod">
   4     %scons;
   5 ]>
   6
   7 <section id="sect-future"
   8          xmlns="http://www.scons.org/dbxsd/v1.0"
   9          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  10          xsi:schemaLocation="http://www.scons.org/dbxsd/v1.0 http://www.scons.org/dbxsd/v1.0/scons.xsd">
  11 <title>Future Directions</title>
  12
  13 <!--
  14
  15   __COPYRIGHT__
  16
  17   Permission is hereby granted, free of charge, to any person obtaining
  18   a copy of this software and associated documentation files (the
  19   "Software"), to deal in the Software without restriction, including
  20   without limitation the rights to use, copy, modify, merge, publish,
  21   distribute, sublicense, and/or sell copies of the Software, and to
  22   permit persons to whom the Software is furnished to do so, subject to
  23   the following conditions:
  24
  25   The above copyright notice and this permission notice shall be included
  26   in all copies or substantial portions of the Software.
  27
  28   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
  29   KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
  30   WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  31   NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  32   LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  33   OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  34   WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  35
  36 -->
  37
  38 <para>
  39
  40   There are a number of things we would like to do to continue to
  41   improve &SCons; in the future.
  42
  43 </para>
  44
  45 <section>
  46   <title>Distutils Cooperation</title>
  47
  48   <para>
  49
  50     There is a certain amount of overlap between what &SCons; does
  51     to search out and make use of various compilers on a system, and
  52     the impressively complete job that the Distutils do of describing
  53     much the same thing. Collaborating to provide some sort of common
  54     interface between the two tools would benefit both tools.
  55
  56   </para>
  57
  58 </section>
  59
  60 <section>
  61   <title>Additional Builder Support</title>
  62
  63   <para>
  64
  65     Adding additional builders would broaden the
  66     potential user base. In rough order of importance:
  67
  68   </para>
  69
  70   <variablelist>
  71
  72     <varlistentry>
  73       <term>Java</term>
  74       <listitem>
  75         <para>
  76
  77           Given the popularity of Java, support for it would greatly
  78           increase the appeal of &SCons; in the large community of Java
  79           users.
  80
  81         </para>
  82
  83         <para>
  84
  85           Good support for Java is, however, a tricky
  86           proposition. Because the Java compiler can make decisions
  87           about compiling other files based on what classes it finds
  88           in a file, it behaves "unpredictably" from the point of
  89           view of an outside build tool like &SCons; or &Make;. Some
  90           sort of sophisticated scanning of Java source code to
  91           identify what other classes are likely to be compiled
  92           would be an obvious first step, but notice that here
  93           &SCons; would be scanning the file to find additional
  94           targets to be built. This is the inverse of the sort of
  95           <literal>#include</literal> scanning performed
  96           for C files, in which &SCons; is looking for additional
  97           <emphasis>dependencies</emphasis>.
  98
  99         </para>
 100       </listitem>
 101     </varlistentry>
 102
 103     <varlistentry>
 104       <term>Documentation toolchains</term>
 105       <listitem>
 106         <para>
 107
 108           A number of early adopters
 109           are using &SCons; to
 110           build documents
 111           from TeX or DocBook source files.
 112           Built-in support for
 113           various documentation toolchains
 114           would be an obvious boon
 115           for many people.
 116
 117         </para>
 118       </listitem>
 119     </varlistentry>
 120
 121     <varlistentry>
 122       <term>C#</term>
 123       <listitem>
 124         <para>
 125
 126           The reality is that anything that Microsoft does will doubtless
 127           have a wide audience. Turning &SCons;' back on that would be
 128           cutting off its nose to spite its face.
 129
 130         </para>
 131       </listitem>
 132     </varlistentry>
 133
 134     <varlistentry>
 135       <term>Fortran</term>
 136       <listitem>
 137         <para>
 138
 139           Despite the fact that &SCons; is no longer directly
 140           associated with Software Carpentry, it still shares the
 141           same goal: to make programming easier for more than just
 142           programmers. To that end, good Fortran support would
 143           help a great many physical scientists and other computer
 144           <emphasis>users</emphasis> out there who still rely on Fortran
 145           for a great deal of their work.
 146
 147         </para>
 148       </listitem>
 149     </varlistentry>
 150
 151   </variablelist>
 152
 153 </section>
 154
 155 <section>
 156   <title>Database Interface</title>
 157
 158   <para>
 159
 160     The Nodes in an &SCons; dependency graph aren't only restricted to
 161     files. Creating an interface to mSQL or MySQL databases would allow
 162     the possibility of updating external files in response to changes in
 163     database fields, or vice versa. This could be handy, for example,
 164     for generating a cache of static web pages from a database that only
 165     need re-generating when the appropriate database objects change.
 166
 167   </para>
 168
 169 </section>
 170
 171 <section>
 172   <title>Tool Integration</title>
 173
 174   <para>
 175
 176     &SCons; should work well with as many popular Integrated Development
 177     Environments (IDEs) and tool chains as possible: Komodo, Microsoft
 178     Visual Studio, ClearCase, etc. Suggestions for additional tools are
 179     welcome.
 180
 181   </para>
 182
 183 </section>
 184
 185 <section>
 186   <title>Makefile Interface</title>
 187
 188   <para>
 189
 190     Because the &SCons; Build Engine can be embedded in any Python
 191     interface, there isn't any technical reason why a &Makefile;
 192     interpreter couldn't be written in Python and use the &SCons; Build
 193     Engine for its dependency analysis.
 194
 195   </para>
 196
 197   <para>
 198
 199     Proof-of-concept for the idea already exists. Gary Holt's
 200     <literal>make++</literal> (also known as <literal>makepp</literal>)
 201     is a Perl implementation of just such a &Makefile; interpreter. It
 202     could possible serve as a model for a Python version, in much the
 203     same way the &Cons; design served as the prototype for &SCons;.
 204
 205   </para>
 206
 207 </section>
 208
 209 </section>