Re: [boost] Boost Testing Dashboard with Dart

From: Brad King (brad.king_at_[hidden])
Date: 2002-01-11 11:29:29

David,

> Are these jamfiles based on what's found in status/Jamfile? This has
> the most sophisticated Jam testing code we have available, and it
> already tests nearly everything.
We looked at it to design the arguments passed to some of the dart-*
testing rules.  Due to Dart's approach to testing, the rules couldn't be
used directly (see below).

> I can currently test all of boost on Windows and Linux machines using
> at least 6 different compilers using status/Jamfile. It seems like
> some coordination would be a big help here.
Definately.  I don't know Jam very well.  Doug Gregor and I hacked our way
through it to get this far.

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.

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.

This implementation is only a first-crack.  The DartTestfile.txt format
supports recursing into sub-directories with their own DartTestfiles.  
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.

-Brad