Vladimir Prus writes:
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.
Right. I think it can wait until after the release, though.
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?
Correctly :). It's still in the path. They already do so for other libraries. -- Aleksey Gurtovoy MetaCommunications Engineering