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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-04-17 03:49:35

On Sunday 15 April 2007 16:42, David Abrahams wrote:
> 
> Volodya and I have been talking about how target alternatives work
> today in Boost.Build.  We seem to agree that something is wrong with
> them, but that's about all.  We have different opinions about what's
> most broken, and therefore different ideas what should be changed. We
> would appreciate if members of this list help us by expressing their
> opinions.
> 
> You can read my proposal at
> http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection
> 
> Volodya will post his ideas, or a link to them, separately.

Here is my ideas what should be fixed.

Let me first recap the case of a target with a single
alternative. Say:

   lib a : a.cpp : <link>static ;

Here, <link>static is "requirement" -- a property
that is guaranteed to be present in build properties for
the target, no matter what. Now consider we want
different files to be used for different toolsets. 
In the current Boost.Build, we'd use:

   lib a : a_msvc.cpp : <toolset>msvc ;
   lib a : a_gcc.cpp : <toolset>gcc ;

and the alternative will be selected depending on the value of
<toolset> feature. But consider this:

   lib a : a_msvc.cpp : <toolset>msvc <link>static ;
   lib a : a_gcc.cpp : <toolset>gcc ;

What the user wants here? It might be
that the user wants the first alternative to be always built
with <link>static, even if other targets are built with <link>shared.
Or user might want <link>static
to affect alternative selection -- -- that is, the appearance of <link>static 
in the build request will affect which alternative is selected.  
The current rules say that the first alternative will be selected 
when both <toolset>msvc and <link>static are in the build request; 
if <toolset>msvc and link>shared are requested, no alternative will match.

My opinion here is that it's bad design to have one syntactic
element to be used both to affect selection of alternatives,
and, once alternative is selected, to affect build properties.
With equal success, we can try to merge default build, requirements
and usage requirements in one parameter.

I believe the fundamental thing about alternative selection is it can fail.
For a trivial example, if we have alternatives for gcc and msvc, we don't
want either to be silently selected when building with borland. I don't
think that toolset is the only special property. You might have hand-coded
assembly files that must be selected depending on target architecture,
or on compiler/architecture combination as well. 

Therefore, for each alternative we should have explicit list of properties
that must be present in build request in order for that alternative to
be selected. I propose an explicit syntax to do that:

   lib a : a.cpp : when <toolset>gcc ;
   lib a : a2.cpp : when <toolset>msvc ;

The selection logic will be simple -- the properties in 'when' clause must
be present in build request for the target, otherwise the alternative is
not considered. If we end up with a single alternative, everything's OK.

When more than one alternative is possible, we compare each pair possible
alternatives. If "when" properties of one alternative are strict subset
of "when" properties of the other alternative, the first alternative is discarded.
For example:

   Alternative #1       : when <toolset>gcc
   Alternative #2       : when <toolset>gcc  <link>static
   Alternative #3       : when <tooset>gcc  <threading>multi ;

If we're building with <toolset>gcc <link>static <threading>single,
alternatives #1 and #2 are viable, and we select #2. If we're
building with <toolset>gcc <link>static <threading>multi, all
alternatives are viable, and we cannot select between #2 and #3,
so it's ambiguity.

Comments?

- Volodya