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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-06-19 02:10:46

Rene Rivera wrote:

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

I don't think we should be thinking about features without context. In this
case, V1 was originally written to support just Boost, where building all
variants unconditionally makes sense when installing.

For external project, building all variants can be a huge waste of time.

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

You can request several variants on the command line, as documentation says:

http://boost.org/boost-build2/doc/html/bbv2/tutorial.html#bbv2.tutorial.hello

> 
>> 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's not at all clear. We can also have 'default build request' that will be
used when no properties are requested on the command line, and ignored if
you specify something on the command line.

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

That's how target alternatives work. If this is not suitable for this
particular case, we need to design some logic that is suitable, and I've
proposed one alternative.

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

So, in a situation when user explicitly requested single threading, he'll
see just obscure "found 3 targets" warning and nothing will be done?

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

Yes, in usage requirement.

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

Can you clarify? IIRC, V1 does not have usage requirements so it can't
produce warning in this situation. What is the situation when the warning
is produced?

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

Already implemented.

> And preferably also specifying them in the default-build of 
> projects and targets. As is possible with BBv1.

Hmm.... I've just checked and it turns out that in V2,

   project : default-build debug release ;
   exe a : a.cpp ;

builds both debug and release versions. And 

   project : default-build debug release 
                           <threading>single <threading>multi ;

builds 4 variants. I'm surprised, I though I explicitly decided this is too
fancy behaviour. Anyway, maybe you can look into using this for building
all necessary variants for Boost?

- Volodya