|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-03-24 03:15:29
David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
>
>> There are two approaches.
>>
>> 1. You have separate configure step. Some tests are compiled and run
>> (much like C++ Boost regression tests) and produce some files. Then,
>> Boost.Build reads those files, decides if tests failed or passed and
>> makes some decision. For this, SHELL is fine.
>>
>> 2. Ideally, the tests are automatically run when out-of-date. The results
>> of tests immediate affect Jamfile logic. For example:
>>
>> if [ configure.run-test have_dlopen.cpp ]
>> {
>> sources += dlopen_using_code.cpp ;
>> }
>>
>> This requires that we be able to update some targets before we've
>> finished reading all Jamfiles, and is not supported at the moment.
>
> Is it a bad idea to think about using a recursive bjam invocation for
> this sort of thing? That is, configure.run-test could invoke bjam to
> update the target associated with have_dlopen.
This is possible, but I'm concerned about performance implications of this.
It's quite feasible to have 100, or 200 tests, running separate bjam for
each one might be too slow. Maybe updating targets in the middle will be
easier.
- Volodya
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk