Re: [Boost-build] [Boost.Build V2] #70: Build all variants

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-06-17 12:01:31

On Saturday 17 June 2006 19:00, Rene Rivera wrote:

> > I plan to address it after we decide that switch of regression
> > testers is done.
>
> I don't see why wait to fix the problem.

Well, there's a number of posts and patches here that I did not replied due to 
being busy last two weeks. I think it's better to sort that first. 

>
> > Of course, if you'd like to help with it, you're much welcome!
>
> If I knew how I would :-)

I think we need to this this multi-variant build only for Boost, and not by 
default by any means. So the best solution would be either:

1. Write a rule that takes a build request, expands it, and declares a number 
of 'alias' targets, each having specific property set in requirements.

2. Write a new main target class that builds a number of targets with a 
specified build request.

The logic could be simular to build-request.jam:

    expanded = [ build-request.expand-no-defaults $(properties) ] ;
    local xexpanded ;
    for local e in $(expanded)
    {
        xexpanded += [ property-set.create [ feature.split $(e) ] ] ;
    }
    expanded = $(xexpanded) ;    

    for local p in $(expanded)
    {
       for local t in $(targets)
       {   
           local g = [ $(t).generate $(p) ] ;
           if ! [ class.is-a $(t) : project-target ]
           {
               results-of-main-targets += $(g[2-]) ;
           }        
           virtual-targets += $(g[2-]) ;
       }        
   }

The user interface could be something like that:

  build $(all-libraries) : debug release <threading>single <threading>multi ;

> >> It also means
> >> that users who have toolset set ups that do not support that particular
> >> build will fail to build, likely silently. That would be the case for
> >> MinGW+STLport5 users at minimum.
> >
> > Can you clarify this point? You mean MinGW+STLport5 does not work in
> > debug mode?
>
> It means that the MinGW + STLport 5.x doesn't work on single-thread
> mode. It's just not supported by STLport. So the stlport.jam has logic
> in it to refuse to build the single-thread variants. In the case of my
> testing it meant that instead of failing it decided to silently test an
> entirely different variant, the MinGW without STLport. I only noticed
> the problem after I was trying to figure out some of the regression
> errors and hence looking at the logs. If I hadn't bothered to look
> carefully I doubt I would have noticed.

Do you refer the the logic in the 'match' method? I believe it was added by 
yourself in revision 1.18 of stlport.jam, so I really can't comment if it's 
right or wrong ;-)

> >> NOTE: The same problem applies when bjam is run for testing!
> >
> > Which problem? For testing we don't need to build 10 variants of libs
> > unless the test are written in a way that requires those 10 variants.
>
> The problem of silently building something other than what you asked for.

Then, this problem is orthogonal to the set of build variants, it's just that 
if you build with <threading>single, STLPort does not get used. As I say, the 
logic there is yours, but we probably need an in-core support, given that the 
situation is the same as with Qt4.

What if we allow to specify non-free features (like <threading>multi), in 
usage requirements, and if the target specifies some values of such feature, 
but is built with another, produce an error?

I don't like the idea to automatically propagate non-free usage requirements, 
since you can suddenly get all your project building with <threading>multi 
without knowing there it comes from. With error, you can consider the 
situation and if MT looks like the right choice, change global requirements.

Thoughts?

- Volodya

- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2