Vladimir Prus <ghost@cs.msu.su> 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com