From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-07-13 04:06:11
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
> 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
> 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