Re: [Boost-build] Target alternatives - one more time

Subject: Re: [Boost-build] Target alternatives - one more time
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2011-07-18 05:37:21

Hi,

Am Freitag, 15. Juli 2011, um 17:58:49 schrieb Edward Diener:
> I tried this:
> 
> test-suite some_dbg
> 
>          [ compile-fail debug_fail_program.cpp
> 
>            : <variant>debug
> 
>              <cxxflags>-std=c++0x
>          ]
> 
>     <toolset>gcc
>     ;
> 
> test-suite some_dbg
> 
>          [ compile-fail debug_fail_program.cpp
> 
>            : <variant>debug
> 
>          ]
> 
>     <toolset>msvc
>     ;
> 
> test-suite some_dbg ;
> 
> Only to get a Build error when I tried to invoke it with the toolset
> msvc-10.0:
> 
> error: No best alternative for ./debug_fail_program
>      next alternative: required properties: <variant>debug
>          matched
>      next alternative: required properties: <variant>debug
>          matched
> 
> How can I get this to work without having to create some sort of rule ?
> This can not be rocket science but I can not understand why Boost Build
> is making something that should so easy end up so difficult to do.
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build

As far as I understand the internal guts of boost-build, the target 
alternative selection does not work that way. Perhaps the error message "No 
best alternative ..." ist somewhat missleading. In my experience boot-build is 
not looking for the "best matching" alternative but for the _only_ matching 
one.
In your case you're providing one alternative for debug_fail_program that is 
only applicable when <cxxflags>-std=c++0x is set, while the other one does not 
impose any further restrictions. So while you may consider the first one a 
"better match" because of the extra restriction, boost-build sees two 
alternatives which both meet all their imposed restrictions.

Also, there may be another reason:
cxxflags is a "free" feature, it may not be usable for alternative selection at 
all for technical reasons. boost-build does not know about the (infinite set 
of) possible values for the feature and their semantics so it can't make 
decisioins based on them.

Basically, I found alternative selection only working for things like:
lib foo : foo.cpp : <link>static ;
lib foo : foo.cpp bar.cpp : <link>shared ;

Here the feature link has two mutually exclusive values, static and shared, so 
it's always clear which one to pick.

Be aware that this is only what I think is happening, I'm not completely sure.

@Vladimir:
Perhaps you could shed some light on this issue and provide the hard technical 
facts? It's an issue that has been interesting me for a long time.

Greetings,
Moritz

-- 
--
AB+M GmbH 
Haid-und-Neu-Straße 7
76131 Karlsruhe
Telefon: [phone]
Telefax: (0721) 66488-18
Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845