Re: [jamboost] Test arguments and input files docs?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-02-01 16:31:37

At 09:04 AM 2/1/2003, David Abrahams wrote:

>Beman Dawes <bdawes_at_[hidden]> writes:
>
>> Regression test programs can be passed arguments, and can have input
>files.
>>
>> Is this documented anywhere?
>>
>> The only documentation I found was in some comments in status/Jamfile:
>>
>> test-suite config
>> : [ run libs/config/test/config_test.cpp
>> <lib>../libs/test/build/boost_test_exec_monitor
>> : #args
>> : #input-files
>> : #requirements
>> <threading>multi
>> ]
>> ...
>
>Not as well as it should be, but testing.jam shows the signature:
>
>rule run ( sources + : args * : input-files * : requirements * : name ? : 

>default-build * )

Even the briefest of documentation would be a big help for new users.

It would be great if someone could contribute a page about using 
testing.jam. Wouldn't need to be reference quality documentation - just a 
description of how to accomplish common tasks would be very helpful.

>...
>That's because, for whatever reason, John chose to ignore the
>input-files argument and sick the test files into the unparsed
>command-line arguments. In doing so, he gives up important
>advantages, including the ability to specify the input files with a
>path relative to the Jamfile directory, and most importantly, a build
>dependency that causes the tests to be re-run when the input files
>have changed.

He may have not realized that was the impact.

>> This came up in some conversations with the Spirit folks, who are in
>> process of integrating Spirit with the regular Boost regression 
testing.
>
>I'm really glad we'll have spirit tests in the suite soon!
>I guess I really should get the Python tests integrated, hm?

The Spirit folks provided an initial Jamfile, which seems to work fine, so 
I don't see any reason not to subinclude Spirit from the main 
status/Jamfile.

They also want to make sure their examples compile and run, and that was 
the context of us wondering about testing facilities.

With the Python tests, aren't there a few tool-chain dependencies?

I think we are going to need to be able to turn off certain tests from the 
command like, so that people who don't have Python installed could still 
run the rest of the tests.

--Beman