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 14:35:49

On Sunday 26 October 2008 21:17:51 Mat Marcus wrote:
> On Sun, Oct 26, 2008 at 4:46 AM, Vladimir Prus <ghost_at_[hidden]> wrote:
> > On Sunday 26 October 2008 00:20:17 Steven Watanabe wrote:
> >> AMDG
> >>
> >> Mat Marcus wrote:
> 
> [snip]
> 
> >> > 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?
> 
> Thanks for working on this. I'd love to see some kind of solution in
> 1.37.0 :-). Flipping the default sounds like it could do the trick.
> 
> In general, though, I would like to see a property corresponding to
> each option. Have you ever considered this? This way I could set
> "defaults" for my boost dependent, boost-build-built libraries, so
> that my clients can issue the simplest possible bjam command line. For
> the case of a preserve-test-targets property, some but not all of my
> tests targets are useful outside of the build process. I could imagine
> choosing to set the preserve property by default for my useful targets
> but not others. In the past I've wished for option-as-feature for
> things options such as --without-python, etc. to reduce warning noise
> and to speed up build times (by eliminating the python invocation).

We actually talked about 'configure' framework, so that you could inform
Boost.Build of your preferences once, as opposed to repeatedly saying things
on command line. Of course, it should be possible to specify things like
presense/locations of external libraries, or which components to build.
I don't really know if features framework will be fully capable of expressing
everything -- but we'll see.

- Volodya