doc/design/issues.sgml

   1 <!--
   2
   3   Copyright (c) 2001, 2002, 2003 Steven Knight
   4
   5   Permission is hereby granted, free of charge, to any person obtaining
   6   a copy of this software and associated documentation files (the
   7   "Software"), to deal in the Software without restriction, including
   8   without limitation the rights to use, copy, modify, merge, publish,
   9   distribute, sublicense, and/or sell copies of the Software, and to
  10   permit persons to whom the Software is furnished to do so, subject to
  11   the following conditions:
  12
  13   The above copyright notice and this permission notice shall be included
  14   in all copies or substantial portions of the Software.
  15
  16   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
  17   KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
  18   WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  19   NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  20   LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  21   OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  22   WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  23
  24 -->
  25  <para>
  26
  27    No build tools is perfect.
  28    Here are some &SCons; issues that
  29    do not yet have solutions.
  30
  31  </para>
  32
  33  <section>
  34  <title>Interaction with SC-config</title>
  35
  36    <para>
  37
  38    The SC-config tool will be used in the &SCons; installation
  39    process to generate an appropriate default construction environment
  40    so that building most software works "out of the box" on the
  41    installed platform.  The SC-config tool will find reasonable default
  42    compilers (C, C++, Fortran), linkers/loaders, library archive tools,
  43    etc. for specification in the default &SCons; construction
  44    environment.
  45
  46    </para>
  47
  48  </section>
  49
  50  <section>
  51  <title>Interaction with test infrastructures</title>
  52
  53    <para>
  54
  55    &SCons; can be configured to use SC-test (or some other test tool)
  56    to provide controlled, automated testing of software.  The &Link;
  57    method could link a <filename>test</filename> subdirectory to a build
  58    subdirectory:
  59
  60    </para>
  61
  62     <programlisting>
  63         Link('test', 'build')
  64         SConscript('test/SConscript')</programlisting>
  65
  66    <para>
  67
  68    Any test cases checked in with the source code will be linked
  69    into the <filename>test</filename> subdirectory and executed.  If
  70    &SConscript; files and test cases are written with this in mind, then
  71    invoking:
  72
  73    </para>
  74
  75     <programlisting>
  76         % sccons test</programlisting>
  77
  78    <para>
  79
  80    Would run all the automated test cases that depend on any changed
  81    software.
  82
  83    </para>
  84
  85
  86    <!--
  87
  88          YYY    integrate with SC-test to provide sanity check on new tools
  89                 "discovery testing" of new tools
  90                 results recorded in a central database
  91                 central database can be somewhere else on web
  92
  93    -->
  94
  95  </section>
  96
  97  <section>
  98  <title>Java dependencies</title>
  99
 100    <para>
 101
 102    Java dependencies are difficult for an external dependency-based
 103    construction tool to accomodate.  Determining Java class dependencies
 104    is more complicated than the simple pattern-matching of C or C++
 105    <literal>#include</literal> files.  From the point of view of an
 106    external build tool, the Java compiler behaves "unpredictably"
 107    because it may create or update multiple output class files and
 108    directories as a result of its internal class dependencies.
 109
 110    </para>
 111
 112    <para>
 113
 114    An obvious &SCons; implementation would be to have the &Scanner;
 115    object parse output from <command>Java -depend -verbose</command> to
 116    calculate dependencies, but this has the distinct disadvantage of
 117    requiring two separate compiler invocations, thereby slowing down
 118    builds.
 119
 120    </para>
 121
 122  </section>
 123
 124  <section>
 125  <title>Limitations of digital signature calculation</title>
 126
 127    <para>
 128
 129    In practice, calculating digital signatures of a file's contents is a
 130    more robust mechanism than time stamps for determining what needs
 131    building.  However:
 132
 133    </para>
 134
 135    <orderedlist numeration="arabic">
 136
 137     <listitem>
 138     <para>
 139
 140      Developers used to the time stamp model of &Make; can initially
 141      find digital signatures counter-intuitive.  The assumption that:
 142
 143      <programlisting>
 144         % touch file.c</programlisting>
 145
 146      will cause a rebuild of <filename>file</filename> is strong...
 147
 148     </para>
 149     </listitem>
 150
 151     <listitem>
 152     <para>
 153
 154      Abstracting dependency calculation into a single digital signature
 155      loses a little information:  It is no longer possible to tell
 156      (without laborious additional calculation) which input file dependency
 157      caused a rebuild of a given target file.  A feature that could
 158      report, "I'm rebuilding file X because it's out-of-date with respect
 159      to file Y," would be good, but an digital-signature implementation of
 160      such a feature is non-obvious.
 161
 162     </para>
 163     </listitem>
 164
 165    </orderedlist>
 166
 167  </section>
 168
 169  <section>
 170  <title>Remote execution</title>
 171
 172    <para>
 173
 174    The ability to use multiple build systems through remote execution
 175    of tools would be good.  This should be implementable through the
 176    &Job; class.  Construction environments would need modification
 177    to specify build systems.
 178
 179    </para>
 180
 181  </section>
 182
 183  <section>
 184  <title>Conditional builds</title>
 185
 186    <para>
 187
 188    The ability to check run-time conditions as suggested on the
 189    sc-discuss mailing list ("build X only if: the machine is idle /
 190    the file system has Y megabytes free space") would also be good,
 191    but is not part of the current design.
 192
 193    </para>
 194
 195  </section>