troy d. straszheim wrote:
same code. The "before" picture:
326.17s user 153.82s system 92% cpu 8:40.03 total
the first ~30 seconds of which is bjam calculating the dependencies for each test module.
To add to what Dave said... We've been personally bitten by assuming that bjam is slow in certain places. Only to humiliate ourselves after looking at the profile data :-)
The "after" test_many.cpp hack starts compilation after ~4 seconds of bjam checking dependencies, with a total time of
99.52s user 41.00s system 93% cpu 2:30.51 total
I'm assuming you deleted the results from the previous run, right?
1) The test_many.cpp above is a hack. It would seem cleaner to have the test modules listed in the Jamfile and have bjam invoke the compiler as
cc test1.cpp test2.cpp ... testN.cpp
is there a clean way to do this?
Yea... You just put all the sources into the bjam target. For example: run test1.cpp test2.cpp test3.cpp : : : std::locale-support : my_test : debug ;
3) There are "demo" tests in the Jamfile, which are pulled in and compiled as tests by #defining main to test_main and #including the .cpp from the examples directory. This means these demos need
<lib>../../test/build/boost_prog_exec_monitor
not boost_unit_test_framework. I'm stumped on this one. How to split up the tests into two groups, each of which takes different libs? Should one toss these from the standard testing run completely and just put a separate Jamfile over in examples/ ? You could get the same code into both the tests and the examples by taking the contents of main() out into some other #inlcuded file, but then the examples would get obscured. Dunno.
I don't understand your confusion. You just do exactly what you said you want to do and refer to <lib>../../test/build/boost_prog_exec_monitor in the sources for those example/tests. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org