Re: [Boost-build] <asynch-exceptions>on cannot be specified in usage-requirements

From: David Abrahams (dave_at_[hidden])
Date: 2006-12-28 14:38:11

Vladimir Prus <ghost_at_[hidden]> writes:

> On Tuesday 19 December 2006 00:28, David Abrahams wrote:
>
>> > Because if you allow non-free usage requirements, then in:
>> > 	
>> > 	exe a : a.cpp lib1 lib2 ;
>> >
>> > usage requirements brought by lib1 might well affect some
>> > conditional requirements in lib2, and in order to figure out the
>> > final properties for all targets you potentially need to take
>> > multiple passed though all targets, re-computing usage requirements
>> > and propagating all the way up and down. I never had time or
>> > motivation to spell down such an algorithm.
>> 
>> As a first cut, you could just turn it into an error if you find
>> conditional requirements that depend on usage requirements.  That
>> would allow the user to explicitly request the build properties that
>> come from the usage requirement from the command-line, thereby driving
>> the conditions from the top down.
>
> It would still be somewhat awkward algorithm. For
>
> 	exe a : a.cpp lib1 lib2 ;
>
> you need to build both lib1 and lib2, get their usage requirements, and if
> any includes non-feature features, build one of the targets, or sometimes both,
> again. So, it's twice the work and I'm not sure how it will scale for deep
> target dependencies. 

Usage requirements don't have to propagate back to siblings and their
children.  Again, if a usage-requirement causes a change in any
dependencies I think it's reasonable to tell the user, "can't build it
that way; put foo=bar on the command line to make it build."

> I'd rather if Boost.Test said "I want the dependents to request
> <async-exceptions>on" and fail if it's not the case. Then, the user
> can request that property from the command line, or project
> requirements.

I think that's too limiting.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com