Re: [Boost-build] ** Need input on alternative selection **

From: David Abrahams (dave_at_[hidden])
Date: 2007-04-19 00:52:13

on Thu Apr 19 2007, "Konstantin Litvinenko" <Konstantin.Litvinenko-AT-malva.ua> wrote:

> Hello, David!
> You wrote  on Wed, 18 Apr 2007 11:01:27 +0100:
>
>  ??>>     Ok. Lets take slightly modified example 3 from your proposal
>  ??>>
>  ??>> lib a : a.cpp ;                                      # 1st alternative
>  ??>> lib a : a-dbg.cpp : <threading>multi <debug-symbols>on ;  # 2nd
>  ??>> alternative exe test : test.cpp a ; bjam invocation will be bjam
>  ??>> debug-symbols=on With your proposal 'test' target will be build
>  ??>> against single threaded runtime, but 'a' will be build against multi
>  ??>> threaded runtime. For VC 7.1 its fatal mistake.
>
>  DA> This particular mistake is easy -- even trivial -- to make today even
>  DA> without target alternatives.
>
>  DA>        lib a : a.cpp : <threading>multi ;
>  DA>        exe test : test.cpp a ;
>
>  DA>   and
>
>  DA>        bjam test
>
>     That is because we have buggy behaviour when only one alternative 
> exists. 

Absolutely not.

You may not like the behavior, but it is not a bug; it is an
intentional feature.  Most properties do not create actual link
incompatibility, and being able to link together objects with
different settings for those features is considered to be desirable.

In the original design for BBv2, we had an attribute that allowed one
to specify that certain properties, when in conflict, were
link-incompatible, and should cause an error.  IIUC Volodya removed
support for that attribute after determining that there were no
properties for which enforcing consistency was more important than
having the flexibility to have inconsistency.  Search the list
archives for "link incompatible;" you may find the rationale.

Removing the link-incompatible attribute may have been the wrong
choice, but I went along with it at the time based on the available
information.

> Above will fail if we fix it. In past when we had link incopability 
> features above can't be executed.

So you know about the link incompatibility concept.  Then surely you
know that the current behavior was a conscious choice.

>  DA> We need to decide if <threading>single with <threading>multi is
>  DA> a link incompatibility on this platform, and we need to decide
>  DA> if we want to enforce that they not be combined.
>
>     Here you are right.

In that case, in all modesty, the other part of what I wrote is right,
too.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com