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

Subject: Re: [Boost-build] Target alternatives - one more time
From: Vladimir Prus (ghost_at_[hidden])
Date: 2011-07-18 09:50:10

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.

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build: http://boost.org/boost-build2