From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-11 12:15:04
----- Original Message -----
> Dart's approach uses a separate build/test setup. The jamfiles in the
> tarball do the build portion for run-tests, run-fail-tests, compile-tests,
> and link-tests. Other jamfiles are generated by this process for
> compile-fail and link-fail tests. All the commands help write out a
> "DartTestfile.txt" describing where to find all the tests. Dart's testing
> stage then reads the tests from this file and runs them. The run-fail,
> compile-fail and link-fail tests are implemented by running a Tcl script
> to run Jam on the corresponding jamfile (generated by the main jam build),
> that captures the output and flips the result code.
There are some problems with that:
The first is that one of the biggest reasons to use Jam is that we can avoid
making the build/test system a pile of scripts written in a dozen different
languages that no one person has the expertise to understand. Too many GNU
tools are like this; it makes them impenetrable and hard-to-use.
The second is that we build information into the Jam rules which allow them
to run arbitrary executables. For example, how will you test an executable
that links to a shared library built by the system? The Jam rules do that
automatically, by transmitting the cumulative LD_LIBRARY_PATH requirements
through the dependency graph.
> The problem on windows is that the generated DartTestfile.txt files use
> windows-style paths. When these are loaded by Dart in Tcl, the
> backslashes are treated as escape sequences. Something in the jamfiles
> needs to flip the slash direction when generating the DartTestfile.txt,
> but not any of the build-fail jamfiles.
That's trivial to fix: $(variable:T) changes any backslashes in $(variable)
to forward slashes.
> This implementation is only a first-crack. The DartTestfile.txt format
> supports recursing into sub-directories with their own DartTestfiles.
"Recursive make considered harmful". This is another reason to use Jam's
> The relative path to the test shows up on the dashboard test summary page.
> This will help group tests by library. More sophisticated Jamfiles will
> be needed to write these out, however.
I would really rather see a solution where Dart is doing less of the work,
e.g. just processing the output of running Jam.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk