Re: [Boost-build] semantics of requirements

From: Deane Yang (deane.yang_at_[hidden])
Date: 2008-02-07 23:29:07

David Abrahams wrote:
> 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.

Which is exactly why I would defer to you two! I am pretty sure I am the 
one who is doing the muddled thinking.

> 
> 
> 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.
> 

Agreed! I honestly don't know where the problem is and certainly should 
not be offering "solutions" like I tried. This could simply be either a 
documentation issue or a case of me not reading the documentation 
carefully enough. At least, I was hoping that's what it was and someone 
would tell me, "please just read this and this more carefully".

Thanks for the belated response.