Re: [Boost-build] explicitly-specified values of non-free feature <threading> conflict

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:
> AMDG
>
> 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
> tools/check_build.
>
> 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.

>
>> /var/lib/jenkins/jobs/Boost-Testing-master-64/workspace/boost_bb/src/build/feature.jam:
>> 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

Phillip