summaryrefslogtreecommitdiffstats
path: root/doc/python10/future.xml
blob: 272d5085c5a44837ef3a763c732217670b24752e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
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>