Closed karzhenkov closed 6 years ago
But that this mean that the interface has changed now and that the user needs to use threadapi-feature
?
The module threadapi-feature.jam
is new, so there is no problem. The name of feature it defines is still <threadapi>
.
Ok.
It is not working yet.
https://ci.appveyor.com/project/viboes/thread/build/1.0.134-develop/job/tj7us66lyvxkbctl
I've applied the patches locally and the build works on my macos. However the test doesn't work.
There are some changes on test/Jamfile.v2 that I have not.
It is better after doing the cleanup as described here test/Jamfile.v2 https://github.com/boostorg/thread/commit/f67e6d44171c30df0819ab62238b0a18941baea1#diff-e97299ad55a4013dc19889043aa464a5
test/Jamfile.v2 is the same in boostorg/thread@f67e6d4 and boostorg/thread@b128586, isn't it?
Did you add <conditional>
to Jamroot
?
Yes, sorry, I didn't read correctly.
And yes, I did it locally.
I can't reproduce the error you got. With clean checkout of top-level develop
branch (boostorg/boost@3f32a98) test is started normally. There is no message "error: No best alternative for libs/thread/build/thread_sources". Could you check again?
I said "It is better after doing the cleanup as described here test/Jamfile.v2"
test/Jamfile.v2
in develop
is reverted to state it had before #160. The cleanup you point to does actually this rollback.
Did I miss something? Is there still the test error?
Everything is ok :)
Thanks for working on this.
This is last step of moving
<threadapi>
and its auto-detection rule toBoost.Build
. Previous PRs are boostorg/build#251 and boostorg/boost#166.