No build tools is perfect. Here are some &SCons; issues that do not yet have solutions.

The SC-config tool will be used in the &SCons; installation process to generate an appropriate default construction environment so that building most software works "out of the box" on the installed platform. The SC-config tool will find reasonable default compilers (C, C++, Fortran), linkers/loaders, library archive tools, etc. for specification in the default &SCons; construction environment.

&SCons; can be configured to use SC-test (or some other test tool) to provide controlled, automated testing of software. The &Link; method could link a test subdirectory to a build subdirectory: Link('test', 'build') SConscript('test/SConscript') Any test cases checked in with the source code will be linked into the test subdirectory and executed. If &SConscript; files and test cases are written with this in mind, then invoking: % sccons test Would run all the automated test cases that depend on any changed software.

Java dependencies are difficult for an external dependency-based construction tool to accomodate. Determining Java class dependencies is more complicated than the simple pattern-matching of C or C++ #include files. From the point of view of an external build tool, the Java compiler behaves "unpredictably" because it may create or update multiple output class files and directories as a result of its internal class dependencies. An obvious &SCons; implementation would be to have the &Scanner; object parse output from Java -depend -verbose to calculate dependencies, but this has the distinct disadvantage of requiring two separate compiler invocations, thereby slowing down builds.

In practice, calculating digital signatures of a file's contents is a more robust mechanism than time stamps for determining what needs building. However: Developers used to the time stamp model of &Make; can initially find digital signatures counter-intuitive. The assumption that: % touch file.c will cause a rebuild of file is strong... Abstracting dependency calculation into a single digital signature loses a little information: It is no longer possible to tell (without laborious additional calculation) which input file dependency caused a rebuild of a given target file. A feature that could report, "I'm rebuilding file X because it's out-of-date with respect to file Y," would be good, but an digital-signature implementation of such a feature is non-obvious.

The ability to use multiple build systems through remote execution of tools would be good. This should be implementable through the &Job; class. Construction environments would need modification to specify build systems.

The ability to check run-time conditions as suggested on the sc-discuss mailing list ("build X only if: the machine is idle / the file system has Y megabytes free space") would also be good, but is not part of the current design.