Re: [Boost-build] semantics of requirements

From: David Abrahams (dave_at_[hidden])
Date: 2008-02-07 16:04:53

on Thu Nov 08 2007, Deane Yang <deane_yang-AT-yahoo.com> wrote:

> Vladimir Prus wrote:
>
>> 
>> Let me try again. 
> A real-world project might have 100 targets. It's
>> very likely that some of the targets have some requirements, and
>> requirements are currently documented as "property that will
>> always be present in build properties". It's not documented as
>> "property that should be present in build request to this target to
>> even build".
>> 
>
> <snip>
>
> I have to be honest. You and David are much, much more experienced at 
> both software development and, specifically, designing the behavior of 
> Boost Build v2 than me. So I would definitely defer to your judgments.

It's unlikely that we would agree, though ;-)

> I would only venture to say this:
>
> It appears that Boost Build was originally designed for very large 
> projects involving 100 targets, which  would probably consist of a 
> smaller number of libraries but built with different settings (static 
> vs. shared, single vs. multi threading, etc.). For example, the Boost 
> libraries. Also, it is often run as part of an automated process. So you 
> have a strong preference for "keep building if at all possible, even if 
> it is not what the user asked for".
>
> The problem is that some of us use Boost Build for much, much smaller 
> projects, where we have fairly specific settings we want, and we don't 
> want the library or application built at all if Boost Build is confused 
> by what we are requesting. Because it is probably us who are confused, 
> not BB.

I think the way you're speaking about this is dangerous, because it can
lead to muddled thinking.

BB can never be "confused about what you're requesting" unless your
request is ambiguous with respect to the formal definition of the
request language.  In that case, of course, BB should issue an error.
For each possible request, we have a choice about how to define the
language: shall it be considered an error or shall it have well-defined
semantics.

> Is it possible maybe to allow for a way to have a "small project 
> setting", say in the user-config.jam file, that cause BB to not build a 
> target (or maybe even just abort the build) if the requested settings 
> are not possible *and* produce a helpful error message listing all of 
> the properties, how they were set (for example, if they were set in a 
> particular Jamfile or Jamroot, report which one) and explaining where 
> the contradiction is.

Basically what you're asking for is a setting wherein the semantics of a
request are different than what they are today.  It would be better to
find a single request semantics that works for everyone, if possible.

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com