Aleksey Gurtovoy wrote:
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.
'get-library-name' will be passed "bin\\boost\\libs\\numeric\\ublas\\test1", though, not "bin\\boost\\libs\\numeric\\ublas\\test1\\test1.test".
Well, first of all, when I create a separate test Jamfile for uBLAS and subinclude it, I get: Cannot extract library name from path ../libs/numeric/ublas This is because when it's in status, 'get-library-name' just returns empty string. When it's not in status, the 'get-library-name' rule is called with ../libs/numeric/ublas and the first regex does not match because there's no "test" in the name, and second regex does not match because there is slash between "numeric" and "ublas". I've applied the attached patch -- since it strictly adds the set of arguments to 'get-library-name' on which that function does not fail, I think it should not cause any problems. Another question whether all libraries should have their test Jamfiles under "test" directory -- which is not what uBLAS does. And now back to original question. As I understand, the 'get-library-name' rules gets the location of *Jamfile*. The primary heuristic is that location is "libs/ <library-name> / test / whatever". Why can't this logic be applied to the name of source file which bjam prints -- and be implemented in process_jam_log. I'm asking because it seems to be that it's better to have smart logic in process_jam_log than in jam. - Volodya