Aleksey Gurtovoy wrote:
Part of your patch that I already committed + our fix to "testing.jam", yes. Your full second patch, no. The reason we append the library name in "testing.jam" instead of doing it in "process_jam_log" is that at the point of parsing the old bjam log's
boost-test(RUN) "test1" : "libs\numeric\ublas\test1\test1.cpp" "libs\numeric\ublas\test1\test11.cpp"
line you have no clue whether the test's *output directory* will be
bin\boost\libs\numeric\ublas\test1.test
or
bin\boost\status\test1.test
There's one gotcha. uBLAS actually have duplicate definitions for tests. There's libs/numeric/ublas/test1/Jamfile, which defines a single target of type "exe", and there's status/Jamfile (which will be moved to libs/numeric/ublas, which defines "run" target with exactly the same sources). This duplication is really bad, so it would be desirable to just "refer" to ublas/test1/Jamfile from ublas/Jamfile. This is something that Boost.Build V2 Jamfile written by Michael does. But then the target path will be not bin\boost\libs\numeric\ublas\test1.test but bin\boost\libs\numeric\ublas\test1\test1.test I wonder how regression tools can determine the library name in that case? - Volodya