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.
Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk