Re: [jamboost] Separation of testing front- and back-ends.

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-15 22:59:07

----- Original Message -----
From: "Brad King" <brad.king_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Tuesday, January 15, 2002 10:54 PM
Subject: Re: [jamboost] Separation of testing front- and back-ends.

> Dave,
>
> I have created another sample implementation of the testing front-end.
> The following changes are included:
>
> 1.) Split up into module files as in tools/build/new.
> 2.) Added user configuration of default tester.
> 3.) General support for introducing new rule types.
>
> It is probably easiest to begin reading the Jamfile, then test.jam, and
> then demo.jam. The foobar.jam is an example of how to define new test
> types. If you can think of a cleaner way to add test types, please
> suggest it.
>
> Some remaining issues were:
>
> 1.) Whether to run a test if it is up-to-date.
> 2.) Up-to-date marker for a test / output file.
> 3.) Controlling how a run-* test is invoked (ex. for debugger).
>
> I think that these issues should be up to the testing back-end, at least
> to some degree. The front-end serves the purpose of collecting test
> information and passing it on to the back-ends. It is the job of the
> back-end to actually implement the test given a target. Some support from
> the front-end may be needed to create both a target for forcing test
> execution and a target for updating a test, but I don't know for sure yet.
>
> Thoughts?
> -Brad

Just one flitting through my brain: a testing back-end is analogous to a
toolset, so choice of which backends get to generate dependency graphs
probably ought to be handled via build properties and the build request.
Some of this is discussed on the Wiki at
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_D
esign_Proposal. The Wiki pages on Boost.Build are a bit of a mishmosh,
definitely, but worth a look.

BTW, it has been suggested that pseudotargets ought to be generated which
depend on large categories of targets determined by implicit features, so
for example "jam gcc" would build everything with gcc. Your command-lines
could still be used, in keeping with that.

-Dave