Vladimir Prus writes:
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.
Unfortunately, it did -- it was producing a composite library name with back instead of forward slashes ("numeric\ublas" instead of "numeric/ublas"), and that confused process_jam_log, causing uBLAS disappear from the report. Fixed in the CVS now, together with a test case to prevent future disturbance ("tools\build\v1\test\test-testing.jam").
Another question whether all libraries should have their test Jamfiles under "test" directory
Yes, http://www.boost.org/more/lib_guide.htm#Directory_structure.
-- which is not what uBLAS does.
For no good reason, IMO. To uBLAS maintainers -- can we fix it sometime after the release?
And now back to original question. As I understand, the 'get-library-name' rules gets the location of *Jamfile*.
No, it is passed the location of the *target output directory*.
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.
Nope, see my original posting -- http://article.gmane.org/gmane.comp.lib.boost.devel/105382.
I'm asking because it seems to be that it's better to have smart logic in process_jam_log than in jam.
Sure, but in this case testing.jam is the only source of the information. -- Aleksey Gurtovoy MetaCommunications Engineering