Subject: Re: [Boost-build] explicitly-specified values of non-free feature <threading> conflict
From: Phillip Seaver (phil_at_[hidden])
Date: 2018-01-22 13:53:03
On 1/17/18 12:46 PM, Steven Watanabe via Boost-build wrote:
> On 01/16/2018 10:01 PM, Steve Robbins via Boost-build wrote:
>> My tester ("Debian-Sid") stopped working December 22. It now fails with the following
>> error. Any idea what it means? Or where to start looking?
> Okay. I've tracked this down to the addition of
> It's a result of an unfortunate combination of factors:
> - Boost.Build does not allow <threading>multi in usage-requirements
> - Boost.MPI tries to set <threading>multi in its usage-requirements
> - Boost.Build mostly ignores the problem and it sort of works,
> except in one case: If a target has a dependency property in
> its usage-requirements.
> - tools/Jamfile.v2 sets <implicit-dependency>/boost//headers (which
> is a dependency property) in its usage-requirements
> - tools/check_build/test inherits this and also uses Boost.MPI,
> thus triggering the error.
> Proposed solution:
> - Boost.Build should ignore non-free usage requirements
> and issue a warning.
Sorry to come in late to the discussion -- I fell behind on keeping up
with this group.Â I don't remember if I try to use a non-free feature in
usage requirements, but it would be nice if you could.Â However, if it
doesn't support it, I think it should be an error.
>> 779: in expand-composites from module feature
>> error: explicitly-specified values of non-free feature <threading> conflict
>> error: existing values: multi single
> In Christ,
> Steven Watanabe
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk