Boost Build creating a couple of invalid directories during test run

I've recently running all the boost tests in order to test
my library status 
facilty before checking it in. In the course of doing this
I've noticed that 
in a couple of cases, bjam doesn't create the proper test
directory.  Here 
are the tests:

a) program_options/test/convert
b) python/test/int_map_indexing_suite
c) statechart/test/TuTest

In all three of these tests (and only these three) the
directory tree is 
missing the test name so that for example, the directory
tree for statechart 
TuTest  looks like

bin.v2/libs/statechart/test/msvc-7.1/debug/link-static/threa
ding-multi/test_log.xml

whereas  I expect the directory tree to look like:

bin.v2/libs/statechart/test/TuTest.test/msvc-7.1/debug/link-
static/threading-multi/test_log.xml

So the test name is missing from the directory - In only
these three cases.

I've repeated this a couple of times with the same results. 
I've been 
unable to determine what these cases have in common which is
different from 
all the other test case.  This shows up a a bogus column in
my library 
status program output for these libraries.

It would be a good idea for someone to look into this.

Robert Ramey



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Robert Ramey wrote:

> I've recently running all the boost tests in order to
test my library
> status facilty before checking it in. In the course of
doing this I've
> noticed that
> in a couple of cases, bjam doesn't create the proper
test directory.  Here
> are the tests:
> 
> a) program_options/test/convert

Note that a target by this name does not exist. There's
'test_convert'
target though. That target is 'exe' target, so it's not a
'test', formally
speaking, therefore no 'test name' is expected in the target
path.

> b) python/test/int_map_indexing_suite

Likewise, the 'int_map_indexing_suite' is defined as
independent
'non-test' target.


> c) statechart/test/TuTest

I'd presume the same here.

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> Robert Ramey wrote:
>
>> I've recently running all the boost tests in order
to test my library
>> status facilty before checking it in. In the course
of doing this
>> I've noticed that
>> in a couple of cases, bjam doesn't create the
proper test directory.
>> Here are the tests:
>>
>> a) program_options/test/convert
>
> Note that a target by this name does not exist. There's
'test_convert'
> target though. That target is 'exe' target, so it's not
a 'test',
> formally speaking, therefore no 'test name' is expected
in the target
> path.
>
>> b) python/test/int_map_indexing_suite
>
> Likewise, the 'int_map_indexing_suite' is defined as
independent
> 'non-test' target.
>
>
>> c) statechart/test/TuTest
>
> I'd presume the same here.
>
> - Volodya
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build 



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:
> Robert Ramey wrote:
>
>> I've recently running all the boost tests in order
to test my library
>> status facilty before checking it in. In the course
of doing this
>> I've noticed that
>> in a couple of cases, bjam doesn't create the
proper test directory.
>> Here are the tests:
>>
>> a) program_options/test/conver
>
> Note that a target by this name does not exist. There's
'test_convert'
> target though. That target is 'exe' target, so it's not
a 'test',
> formally speaking, therefore no 'test name' is expected
in the target
> path.

I get a directory 
bin.v2/libs/program_options/test/msvc-7.1/debug/link-static/
threading-multi

note the absence of test_convert.test.

My reading of process_jam_log.cpp suggests that this is not
expected. The 
test-name is
determined to be blank. Is this OK and should I just ignore
it? or should 
something be done about it.  I'm not sure what the point
would be if the 
results are generated without a corresponding test name.  I
wonder if in 
fact this is what the authors of the Jamfile.v2 intended or
it is an 
oversight that should be addressed.

Robert Ramey



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Sunday 12 August 2007 09:37:04 Robert Ramey wrote:
> Vladimir Prus wrote:
> > Robert Ramey wrote:
> >
> >> I've recently running all the boost tests in
order to test my library
> >> status facilty before checking it in. In the
course of doing this
> >> I've noticed that
> >> in a couple of cases, bjam doesn't create the
proper test directory.
> >> Here are the tests:
> >>
> >> a) program_options/test/conver
> >
> > Note that a target by this name does not exist.
There's 'test_convert'
> > target though. That target is 'exe' target, so
it's not a 'test',
> > formally speaking, therefore no 'test name' is
expected in the target
> > path.
> 
> I get a directory 
>
bin.v2/libs/program_options/test/msvc-7.1/debug/link-static/
threading-multi
> 
> note the absence of test_convert.test.

As I said, "test_convert.test" is not supposed to
be prevent in this case.

> My reading of process_jam_log.cpp suggests that this is
not expected. The 
> test-name is
> determined to be blank. Is this OK and should I just
ignore it? or should 
> something be done about it.  I'm not sure what the
point would be if the 
> results are generated without a corresponding test
name.  I wonder if in 
> fact this is what the authors of the Jamfile.v2
intended or it is an 
> oversight that should be addressed.

For program_options, the target in question is not even
supposed to
be automatically run, and should not be reported.

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus wrote:

>> Is this OK and should I just ignore it? or
>> should something be done about it.  I'm not sure
what the point
>> would be if the results are generated without a
corresponding test
>> name.  I wonder if in fact this is what the authors
of the
>> Jamfile.v2 intended or it is an oversight that
should be addressed.
>
> For program_options, the target in question is not even
supposed to
> be automatically run, and should not be reported.

Hmmm - so I should just ignore it?

For my purposes I would like to see it run with the
directory I expected.
My motivation can be found in something like
libs/serialization/example
which contains a Jamfile.v2 with something like

exe : demo ...

with the intention that the demos be create, run and the
results reported.

I notice that the process_jam_log has special code to filter
out the
example directory so it seems that at one time the exe
targets were
expected to be handled as tests.

I believe that this is way it used to be - but of course I
don't really 
know.

In anycase would you recommend the following:

a) change the Jamfile.v2 in the example directory to use run
rather than 
exe?
b) that authors sholuld do this on all example directories?
c) remove all exe targets from Jamfile.v2 files?
d) ?

Robert Ramey



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build