Re: [boost] Boost Testing Dashboard with Dart

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-11 14:12:30

----- Original Message -----
From: "Brad King" <brad.king_at_[hidden]>

> > I'm not happy with any direction that requires specifying tests in two
> > different languages. Now boost developers either need to install Dart
> > or we have duplicated test specifications. I think either one is
> > unacceptable.
>
> We won't need duplicated test specs.  The solution I was suggesting was to
> have the Jam rules generate the DartTestfiles themselves.

Less odious, for sure. However, it's not what I had in mind and at best it's
going to take some time for me to get comfortable with that approach.

> I'm afraid that
> installing Dart is unavoidable unless you can duplicate the entire
> client-side with Jam code.  Dart is fully interpreted, so "installing" it
> simply means doing a CVS checkout or extracting a tarball.  However, tcl
> may need to be installed.  I don't think this is too much to ask from
> someone capable of coding for boost, and user's won't need to run the
> tests.

Go back and look in the message archives at the strength of the opposition I
heard to the idea of using Python for the build system. I think you'll be
surprised.

> Another idea is to have some jam rules to actually execute Dart.  This
> could be used to get around the LD_LIBRARY_PATH problem.  Jam could have
> generated the list of tests into the DartTestfile, and then setup the
> environment correctly before executing Dart.  This way a test build could
> be done like this (assuming BOOST_ROOT, ALL_LOCATE_TARGET, etc are set in
> the environment already):
>
> jam dart-nightly
>
> Before committing code to CVS, a developer could do this:
>
> jam dart-experimental
>
> We could also provide more fine-grained control by providing separate
> targets for the Start, Update, Build, Test, and Submit steps.
>
> Thoughts?

My major requirements are:

1. Users and developers should be able run all the tests and get readable
output without installing an additional tool (Tcl, Dart...) on their
systems.

2. The testing system should only rebuild the things whose dependencies have
changed

3. There should be no duplication of user-written test descriptions

If any of your ideas can be made to satisfy these criteria, I'm happy with
it. I think dart's nightly test and CVS integration features are valuable,
and I'd like to see something like that happen...on some server somewhere.
I'm uncomfortable with the idea of adding yet another tool to the suite that
a developer needs to have just to build and test Boost.

Can you post a sample of Dart's XML input?

Thanks,
Dave