Re: [jamboost] Re: testing.jam - weird behavior? (Re: 1.30.2 ready for release?)

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2003-08-17 08:17:09

David Abrahams wrote:
> Aleksey Gurtovoy <alexy_at_[hidden]> writes:
> > This one is really nasty. We tracked it down, and it's caused by
yesterday
> > changes in "testing.jam":
> >
> > RCS file: /cvsroot/boost/boost/tools/build/testing.jam,v
> > retrieving revision 1.15
> > retrieving revision 1.15.2.1
> > diff -r1.15 -r1.15.2.1
> > 102c102
> > < local file = $(files[1]:R=$(SUBDIR_TOKENS:J=/) ;
> > ---
> >> local file = $(files[1]:R=$(SUBDIR_TOKENS:J=/)) ;
> > ^^^
> >
> > While the above looks like a right fix to me (not to mention that I have
no
> > idea how the mismatched brackets _could be_ handled without giving a
syntax
> > error)
>
> Jam is notoriously bad about strict parsing in expansion sequences.
>
> > but the fact is that the change caused an unwanted behavior - now,
> > while dumping the tests info, bjam appends an erroneous 'libs\'
> > prefix to the static_assert library test names:
> >
> > [bjam.log]
> > ...
> > boost-test(COMPILE_FAIL) "static_assert_test_fail_8" :
> > "libs\libs\static_assert\static_assert_test_fail_8.cpp"
> > boost-test(COMPILE_FAIL) "static_assert_test_fail_7" :
> > "libs\libs\static_assert\static_assert_test_fail_7.cpp"
> > ^^^^^^^^^
> >
> > This, in turn, leads to erroneous detection of the library name further
in
> > the tools chain, and ultimately to incorrect summary and detailed
regression
> > reports - http://tinyurl.com/jtpd (the yellow cells in the middle).
> >
> > The old revision works exactly as wanted (however weird it is):
> >
> > boost-test(COMPILE_FAIL) "static_assert_test_fail_8" :
> > "libs\static_assert\static_assert_test_fail_8.cpp"
> > boost-test(COMPILE_FAIL) "static_assert_test_fail_7" :
> > "libs\static_assert\static_assert_test_fail_7.cpp"
> >
> >
> > I would appreciate if someone with bjam expertise explained what's
happening
> > here and what would be the right fix.
>
> Can't explain it, but you can do what I would do: add ECHO
> statements to diagnose what values are being seen at each step.

OK, I added the tracing to the testing.jam/dump-test rule:

local files = [ GLOB $(full-paths:D) : $(s:D=) ] ;

if $(files)
{
ECHO "#files:" $(files) ;
# make relative to the project root instead of "."
local file = $(files[1]:R=$(SUBDIR_TOKENS:J=/)) ;
ECHO "#file:" $(file) ;

# try to undo absolute paths
local source-file = [ relative-path $(file) ] ;
ECHO "#souce-file:" $(source-file) ;
source-files += [ relative-path $(file) ] ;
}

and here's what I get:

#files: ..\libs\static_assert\static_assert_test_fail_8.cpp
#file:
libs/static_assert\..\libs\static_assert\static_assert_test_fail_8.cpp
#souce-file: libs\libs\static_assert\static_assert_test_fail_8.cpp
^^^^^^^^^^

I am not quite sure which of these steps is erroneous, but the result is not
what we need. Any further suggestions?

Aleksey