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

From: David Abrahams (dave_at_[hidden])
Date: 2007-04-17 06:17:14

on Tue Apr 17 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com> wrote:

> Dave,
>
> 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
>
> In brief, I believe your proposal makes sense. Intuitively, matches for
> explicitly requested build properties should rank "higher" than matching
> implicit/default properties. Some section-specific comments below. These are
> from a user's perspective only.

That's the only perspective that matters to me (modulo
implementability).

> - "Example 1": Makes sense.
>
> - "Example 2": A bit more convoluted:
>
> Building lib c as described makes sense. IMHO, there's not even a
> contradiction here, as a default is something that only comes into
> play when nothing else is specified.  Here, 'profiling' is
> specified, so logically the default shouldn't even be taken into
> account.

Except that in the case of two alternatives, defaults currently *do*
come into play even if something else is specified.

  lib c : c1.cpp : <debug-symbols>off ;
  lib c : c2.cpp : <debug-symbols>on <profiling>on ;

  bjam debug-symbols=on

will cause an error because <profiling>off (the default) gets combined
with <debug-symbols>on from the command-line to produce a build
request that matches nothing.

My point here is that producing an error in this case is inconsistent
with the logic used when there's only one alternative.

> Building lib b isn't equally obvious to me; if explicitly requesting
> debug-symbols=on and the library _requirements_ is to build with
> debug-symbols=off, should the build just happily execute? Let's consider the
> reasonable alternatives for this specific case:
>
> a) lib b is not built at all. This is flagged as an error, and the build
> stops if the '-q' flag is given at the command-line.
>
> b) lib b is not built at all. This is considered normal, as a requirement
> for building the library is <debug-symbols>off and the generation of debug
> symbols is explicitly requested. If other targets depend on lib b, they will
> cause the build to fail.
>
> c) lib b is built anyway, but with debug-symbols=off (current behavior,
> right). I have to agree that from a usability perspective this is the most
> lenient way. For alternatives a) and b) above, it would otherwise complicate
> things whenever I'd like build my own target depending on lib b with e.g.
> debug-symbols=on optimization=off.

Right.

> So, I guess the current behavior is fine, but I personally would
> like to have a warning output when such a conflict is
> detected. Also, perhaps adding a command-line option to the build
> system that would cause either a) or b) to happen would be an
> interesting feature, e.g.  "bjam --property-matching=strict" (or
> whatever).

All interesting ideas, but they're orthogonal to the question of my
proposal.

> Just a comment on "requirements describe how a target must be built,
> not exactly how it must be requested". Sure, as a general statement that
> makes sense, but requiring a target to be built with "debug-symbols=off"
> with a request for "debug-symbols=on" doesn't sound equally sane, does it
> ;-)

No; my point was only to say that my proposal is consistent with a
principle already expressed by the current semantics.

> - "Example 3": Agreed.
>
> - "Example 4": I honestly don't really follow this one. Haven't got time to
> read the original thread either, sorry.

Let me try to simplify it:

  # configure the default installation of python, which is version 2.3
  using python : 2.3 : /usr : : ; 

  # configure a specific python 2.4 installation for use with gcc-3.4.5_linux
  using python : 2.4 : /usr/local/python/2.4/gcc-3.4.4 : : : <toolset>gcc-3.4.5_linux ;

  bjam toolset=gcc-3.4.5_linux

The current behavior is to use the first installation of python,
because:

  * there is a feature, "<python>," representing the python version
  * its default value is "2.3"
  * that default (<python>2.3) is treated by Boost.Build as being just
    as significant as the explicitly-requested
    <toolset>gcc-3.4.5_linux.

> - "Details on proposed semantics":
>
> Sounds reasonable, but what about requirements specified for the project at
> a higher-level Jamfile? 
> Shouldn't these also be considered explicit, or at
> least higher ranked than the defaults? 

I don't understand.  Example, please?

> Just throwing out an idea off the top of my head: What about ranking
> the properties from e.g. high-to-low: explicit (command-line) =>
> explicit (project requirements) => explicit (target requirements) =>
> implicit (default)? Don't know if that would make sense, though.

Sounds complicated.  Is it driven by a real use-case?

> - "Not a pure extension": As for 1), the answer is 'no'. I like your
> approach here.

Good, because I don't particularly want to implement the optional
extension.  It's a bit messy.

> - "Optional extension to this proposal":
>
> Why not use the same syntax as is already used when setting conditional
> properties (less the resulting property):
>
> <optimization>off,<debug-symbols>on

We currently have two different syntaxes used for combining properties
in different contexts (using ',' or '/').  I don't have an opinion
about which one is better, but we should probably try to settle on
one.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com