Re: [Boost-build] Idiom for running tests using (non-test) target?

Subject: Re: [Boost-build] Idiom for running tests using (non-test) target?
From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-10-26 07:46:11

On Sunday 26 October 2008 00:20:17 Steven Watanabe wrote:
> AMDG
> 
> Mat Marcus wrote:
> > [ It seems that you replied off-list, so I do too this time, in case
> > it wasn't unintentional. Feel free to quote this message on list if
> > you like ]
> >   
> 
> Whoops.
> 
> > On Sat, Oct 25, 2008 at 10:39 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> >   
> >> AMDG
> >>
> >> Mat Marcus wrote:
> >>     
> >>> Thanks, this is a helpful start. Now, when I build the "exe" target,
> >>> the executable builds as expected. But when I run the test, the
> >>> executable gets deleted, even it was built earlier. I'd like to be
> >>> able to invoke bjam a single time, without having to pass
> >>> --preserve-test-targets, so that the test is run *and* the  executable
> >>> is preserved. Is this possible? Put another way, can the run rule make
> >>> use of an existing artifact without deleting it, without having to
> >>> pass options to bjam?
> >>>
> >>>       
> >> Ok.  I think that run should only delete the
> >> targets that it creates,
> >>     
> >
> > I agree!
> >
> >   
> >> but changing it looks non-trivial.
> >>     
> >
> > Sorry to hear it.
> >   
> 
> I'll think about this some more, since this is really the
> best solution.  Wait--make-test sets the <location-prefix>
> feature to a unique directory.  It ought to be possible to
> write a generator that searches the dependency graph for
> targets that have this feature set correctly.
> 
> >> Can you use the unit-test rule instead?
> >>
> >> exe a : a.cpp ;
> >> unit-test a_test : a : <testing.arg>"-a -b -c ..." ;
> >>
> >>     
> >
> > This works, in the sense that it doesn't delete the executable. But it
> > is not a usable workaround for me since the test no longer fits in
> > with the others in my test suite. The unit-test rule uses a different
> > output format from the run rule  (e.g. unit-test writes the test
> > output to stdout instead of to a file), and it looks like it generates
> > different output files.
> >
> > Is there a way to place a property/feature like
> > <preserve-test-targets> somewhere in the run rule?
> >   
> 
> That would be easy.  The test in testing.capture-output
> just needs to change from
> 
>     if ! $(preserve-test-targets)
> 
> to
> 
>     if ! $(preserve-test-targets) && [ property.select 
> <preserve-test-targets> : $(properties) ] == <preserve-test-targets>off

This is probably how it should have being in the first place. The
--preserve-test-target is option, and not a property, only for compatibility
with V1.

But I'm not really sure if the default behaviour should be to remove test targets.
For Boost testing, the scripts can very well pass the right option, and in general,
test program are not likely to use very much space -- since shared linking is default
in Boost.Build, and since object files are not being removed. Should we just flip the
default?

- Volodya