Re: [Boost-build] Liking to pthreads

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-18 16:09:15

Vladimir Prus <ghost_at_[hidden]> writes:

> On Monday 18 September 2006 23:22, David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> > On Monday 18 September 2006 18:06, David Abrahams wrote:
>> >> David Abrahams <dave_at_[hidden]> writes:
>> >> > It is certainly sufficient for glibc and libstdc++, but not for
>> >> > portable building on the "abstract machine."  However, unless James
>> >> > M. has some strong arguments to the contrary, I'm willing to go with
>> >> > the optimization as we currently have it.
>> >>
>> >> Hm, well, good points in private email, James.
>> >>
>> >> Why don't we just make the optimization on platforms where it's known
>> >> to work?  Now that you've implemented it, Volodya,
>> >>
>> >>    -<threading>multi
>> >>
>> >> will work for those who want to disable threading explicitly.
>> >
>> > Where would you put it? That syntax can be only used to cancel parent's
>> > requirements, not to cancel usage requirements from any target.
>>
>> Why not that, too?
>
> Because I did not see obvious use case for that. And <threading>multi is 
> non-free so it can be passed via usage requirements anyway at the moment.

??  If it is non-free and can be passed via usage requirements, this
exact capability would be useful.

>> And what's a "parent?" do you mean a project higher up in the hierarchy?
>
> For a target -- project where the target is defined. For a project -- project 
> higher up.

I can see why it's slightly less dangerous to limit the feature in
that way, but I'm not sure it's worth the cost.  We've long discussed
the desire to say "despite usage requirements, I know better; this
target doesn't have such-and-such requirement."

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