# Other Issues

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

## Interaction with SC-config

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.

## Interaction with test infrastructures

&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

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.

## Limitations of digital signature calculation

In practice, calculating digital signatures of a file's contents is a more robust mechanism than time stamps for determining what needs building. However:

1. 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...

2. 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.

## Remote execution

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.

## Conditional builds

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.