Re: Alternatives and underfined feature values

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-12 16:01:36

Vladimir Prus <ghost_at_[hidden]> writes:

> On Friday 04 February 2005 19:13, Pedro Ferreira wrote:
>
>> >>> 3. Allow the user to say that <toolset>msvc
>> >>> is valid, without initializing the toolset.
>> >>
>> >> I like #3. It seems to be the cleanest of your proposals. In fact I
>> >> think that all toolsets shiped with BB2 should be valid by default.
>> >
>> > This would be great. But I dont think that *automagically* scanning all
>> > toolsets would be a great idea.
>> >
>> >> The same goes for the <os> feature that has the same problem.
>> >
>> > I'm +1 for an explicit list of "configured" values for <toolset> and
>> > <os>. So bjam can check for syntax errors.
>>
>> In principle, I agree but how does one implement it? Hardcoding a list
>> of supported OSs and toolsets?
>> Looks a bit awkward... but I think it's better than the other approches.
>
> So, everybody prefers #3. Now it's time to express my opinion.
>
> I think we absolutely need #2 to fix 
> http://zigzag.cs.msu.su:7814/scarab/issues/id/BB78

I disagree. You could solve that issue by simply ignoring
requirements that weren't directly specified on the target during
alternative selection.

"when" clauses look very explicit, but I'm afraid there might be
redundancy. For example, would

lib a : a_msvc.cpp : <threading>single 
when <toolset>msvc-6.0 ;

be meaningful?

> This means that the *recommended* way to declare alternatives becomes:
>
> lib a : a_msvc.cpp : when <toolset>msvc-6.0 ;
> lib a : a_vc7.cpp : when <toolset>msvc-7.1 ;
>
> I think it's acceptable, given that alternatives are not very common. It's 
> also desirable to retain the existing syntax:
>
> lib a : a_msvc.cpp : <toolset>msvc-6.0 ;
> lib a : a_vc7.cpp : <toolset>msvc-7.1 ;
>
> The question now how to validate the features. The problem only arises for 
> <toolset> and <os> --- which can have unbounded set of values. We also have 
> this problem for STLport -- I can put <stdlib>stlport-4.5-hostios in the 
> condition.
>
> I still like approach #1 -- don't validate such features. 

It does seem reasonable to me that certain kinds of features should
not be fully validated. Maybe we should add a "configured" feature
attribute to indicate it.

> Historically, many 
> checks in V2 ended up being nuisance -- for example
> link-compatibility 

I'm really confused now. I was pretty sure that in editing the docs I
came across a claim that link-compatiblity was still being enforced
and I checked with you and you verified it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com