RE: [boost] uBLAS regressions

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-07-18 22:19:43

Vladimir Prus writes:
> Aleksey Gurtovoy wrote:
> 
> > >    local rule get-library-name ( path )
> > >    {
> > >        local match1 = [ MATCH [/\\]libs[/\\](.*)[/\\]test 
> : $(path) ] ;
> > >
> > > I'm not sure:
> > >
> > > ghost_at_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