Boost logo

Boost-Build :

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 ! [ $(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.


- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at