on cannot be specified in usage-requirements

Vladimir Prus <ghostcs.msu.su> writes:

> On Sunday 17 December 2006 01:04, David Abrahams wrote:
>> Roland Schwarz <roland.schwarzchello.at> writes:
>> 
>> > The test library specifies in its
requirements:
>> >
>> >
<toolset>msvc:<asynch-exceptions>on
>> >
>> > Now when I try to put this also into the
usage-requirements, and try to 
>> > build something that uses the test library
Boost.Build complains with:
>> >
>> > error: usage-requirements
<toolset>msvc:<asynch-exceptions>on have 
>> > non-free properties
<asynch-exceptions>on
>> 
>> That is rather baffling.  I can't see why
usage-requirements should be
>> limited to free properties.
>
> 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.

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

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

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. 

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.

- Volodya





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