Aleksey Gurtovoy wrote:
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.
Yea, because I don't think V1 can refer to test targets in other Jamfile, and V2 can be only used after release.
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.
You mean this: local rule get-library-name ( path ) { local match1 = [ MATCH [/\\]libs[/\\](.*)[/\\]test : $(path) ] ; I'm not sure: ghost@zigzag:/tmp$ bjam -f- ECHO [ MATCH [/\\]libs[/\\](.*)[/\\]test : bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test ] ; numeric\ublas\test1 It's numeric\ublas\test1, not numeric\ublas. - Volodya