Re: [boost] Boost Testing Dashboard with Dart

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
facilities directly.

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

-Dave