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

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

On Tuesday 17 April 2007 13:34, David Abrahams wrote:
> 
> on Tue Apr 17 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
> 
> > consider this:
> >
> >    lib a : a_msvc.cpp : <toolset>msvc <link>static ;
> >    lib a : a_gcc.cpp : <toolset>gcc ;
> >
> > What the user wants here? 
> 
> Presumably the user wants the semantics that the system implements for
> this case, or he would have written something else.  

In another email, I explain why using existing semantic to force
intentions on user is not right.

> > 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.
> 
> It's only bad design if the two issues are unrelated, but they're not.
> They're very commonly correlated, (as my proposal says, "one usually
> wants a target to be built with properties that correspond to what the
> user explicitly requested") and in fact the current design of
> Boost.Build implicitly acknowledges that correlation -- just not as
> fully as it could.

As I said in another email, I don't understand your "one usually
wants a target to be built with properties that correspond to what the
user explicitly requested" and I don't know where that is acknowledged.

> > With equal success, we can try to merge default build, requirements
> > and usage requirements in one parameter.
> 
> That would only be true if they are all strongly correlated.  But
> they're not.

Are you sure? I've heard several person ask if he can avoid specify <include>
both in requirements and usage-requirements.

> > 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. 
> 
> Why is that any worse than silently selecting a single target (with no
> alternatives) whose requirements are <threading>multi when building
> single-threaded?  That is the current behavior.

Because alternatives are used when you can't use a single target, for
whatever reason. If gcc alternative and msvc alternative are needed,
you probably don't want gcc alternative to be used when building with
msvc -- supposedly because it won't compile. Then, even less want
gcc alternative to be used with a random compiler.

> > 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?
> 
> Well, I understand it, but that doesn't make it usable.  My proposal
> is concerned with making real use-cases work out.
> 
> I have two prebuilt libraries, one of which I need to be selected if
> *any* of three properties is present in the explicit build request.
> In my proposal, that is represented as:
> 
>   lib foo : : <name>foo_generic ;
>   lib foo : : <name>foo_dbg <feature1>value1 <feature2>value2 <feature3>value3 ;
> 
> Can you please demonstrate the alternative declarations that would be
> required to achieve the same result using your proposal?

Can you recast this example to use real feature names, and explain why you'd want
this "select if any of those properties are present" behaviour. Although I have
some ideas how to handle this case (independently of my 'when' proposal), I'd like
to first see the real need.

- Volodya