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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-11-08 10:12:31

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

Can you:

1. Provide a couple of cases where the behaviour you ask for would
be helpful for you -- I mean exact settings specified on command line
and in Jamfile.

2. Tell what you expect in this situation:

   exe a : a.cpp helper : <link>static ;
   lib helper : helper.cpp : <link>shared ;

Those are not rhetoric questions -- I'd need better understanding of use
cases where the current behaviour confuses you.

- Volodya