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

Subject: Re: [Boost-build] Target alternatives - one more time
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-18 22:02:52

On 7/18/2011 9:50 AM, Vladimir Prus wrote:
> On Monday, July 18, 2011 13:37:21 Moritz Hassert wrote:
>> 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.
>
> For the start, I should repeat that the best way to solve this problem
> is indirect conditional requirements. Really.
>
> That said, alternative selection works like this:
>
> 1. If the list of requirements of a metatarget is not fully included in
> the build request, that metatarget is skipped.
>
> 2. If there is more than one option remaining, the one with longest list
> of requiremenst wins.
>
> In both cases, only 'non-free' requirements are considered -- those with
> fixed set of values.
>
> In this case we have essentially:
>
> 	compile-fail debug_fail_program.cpp :<variant>debug<cxxflags>-std=c++0x ;
> 	compile-fail debug_fail_program.cpp:<variant>debug ;
>
> The list of non-free requirements both both is identical, so they will never
> be distigguished. Now, a note about [].
> Recall that [ ] is nothing but the syntax for function invocation. So:
>
> 	exe foo : [ obj bar : bar.cpp ] ;
>
> Is almost identical to declaring two targets individually. However, the 'obj'
> function returns a class instance, and then 'exe' notices it was passed a class
> instance, and renames 'bar' to something else internal. This is exactly to
> faciliate inline declarations without conflicts with anything. But 'alias'
> rule (which is what 'test-suite' is) disables this behaviour, so the original
> example creates two metatargets with the same name, which are considered
> as alternatives and therefore result in this error.
>
> Hopefully this clarifies something.
>

The way I would like target alternatives to work, purely from this 
end-user's point of view is:

I can have a number of 'test-suite' ( or 'alias' ), each one associated 
with a particular toolset. No toolset as part of the 'test-suite' means 
any toolset. When I invoke bjam with a toolset name, it finds the most 
specific test-suite for a given for that toolset and ignores the rest. 
So if my toolset when I invoke bjam is 'gcc-4.5.2' and I have a 
'test-suite' named A which has <toolset>gcc and one named A which has 
<toolset>gcc-4.5.2 it uses the latter.

Maybe this is not 'target alternatives' but why my 'test-suite some_dbg' 
can not work that way is beyond me.

Boost build need to think about the end-user, not how the internals 
currently integrate. The end-user saying, for toolset X I want A things 
done this way, while for toolsey Y I want A things done some other way, 
and for toolset Z I want A things done yet another way, where A 
represents a test-suite of items, is an intrinsic way of doing things. 
Stop thinking: we can't do this because Boost Build doesn't work this 
way and start thinking: we will do this because this is one key way 
end-user's build their tests ( applications ).