Re: [Boost-build] semantics of requirements (Was: single threaded build with msvc-7.1?)

From: Deane Yang (deane_yang_at_[hidden])
Date: 2007-11-08 10:05:58

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.

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.

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.

I'm probably asking for something that is unrealistic, and I am open to 
suggestions for what would be a more reasonable request.

Deane