on cannot be specified in usage-requirements

Vladimir Prus <ghostcs.msu.su> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build