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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-06-17 12:40:58

Vladimir Prus wrote:
> 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. 

Yea, that's a good reason :-)

>>> 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.

a) No. I personally use, or at least I did when I was using BBv1, the 
multi-variant build functionality. And this is one of the long standing 
Boost.Build trademark features. I.e. of building multiple variations 
with one invocation.

b) Not sure what you mean. But if you mean not being able to request 
multiple variants from the command line, then I disagree.

> So the best solution would be either:
[...]
> The user interface could be something like that:
> 
>   build $(all-libraries) : debug release <threading>single <threading>multi ;

So basically it would not be possible to request multiple variants from 
the CLI :-(

>>>> 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 ;-)

Well, the original STLport match logic was by Reece and you AFAIK ;-) I 
just changed it to include 5.x. But I refer to the no-match not 
resulting in an error, but instead falling back to some other variant 
which I didn't request when I invoke with "bjam --v2 toolset=mingg 
stdlib=stlport-5.1"

>>>> 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.

I'd be happy with it not building the variant, i.e. no fallback, 
requested if it's not supported. As BBv1 does.

> 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'm not sure I see the logic. Would it mean that the stlport pseudo 
targets would have the <threading>multi?

> 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.

Well definitely propagation is bad :-) BBv1 produced a warning, which 
could be programatically turned off, in this particular situation.

> Thoughts?

Ultimately I think we need to figure out how to support requesting 
multiple variants generally. At minimum a syntax for specifying them in 
the CLI. And preferably also specifying them in the default-build of 
projects and targets. As is possible with BBv1.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo