Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)

Subject: Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-10-03 14:52:49

Le 03/10/15 16:21, Tim Blechmann a écrit :
>> All tests for lockfree in both master and develop branch seem to fail.
>> Error message is
>>
>> "../boost/system/config.hpp", line 34: Error: #error Must not define
>> both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK.
>>
>>
>> See develop branch:
>> http://www.boost.org/development/tests/develop/developer/lockfree.html
>>
>> See master branch:
>> http://www.boost.org/development/tests/master/developer/lockfree.html
>>
>> I looked at lockfree/test/Jamfile.v2 but am not sure what change needs
>> to be made.
>>
>> Any suggestions?
>
> boost lockfree's testsuite hasn't changed for a long time. i have no
> idea why the tests are failing, so something must have changed in
> boost.test.

The current master on boost.test is pointing to the released version 
1.59. Were those problems already there for 1.59?

> if the boost.test developers push some changes, it would be highly
> appreciated if people could actually check if the change doesn't
> introduce any issues for other libraries. i've had a similar issue with
> boost.test in one of my boost libraries in the past, where all tests on
> the master branch failed, while tests on the develop branch passed. as
> the tests of many boost libraries depend on boost.test, i'd suggest to
> run the complete tests of *all* boost libraries before pushing a change ...

Right. OTOH, the runners are there on develop for being able to test 
those changes. Right now I do not know what would be the best strategy: 
resetting develop to the commit before the problems started, or fixing 
the issues.
This does not help boost.test very much since:
- we cannot take full benefits of the runners: as soon as there is an 
issue with boost.test, it breaks a lot of other libraries. Which makes 
the current testing procedure of boost.test quite fragile. We need to 
deploy our own runners somehow.
- as a central library, any change in design in boost.test is spanning a 
lot of libraries, including the not so maintained ones, which is a waste 
of efforts.

It looks like the best way to cope with those issues is to have a 
boost.test2 (test3 in fact), but that is also a bit confusing for end 
users.

>
> ---
>
> fwiw, maybe one of the boost.test developers has an understanding,
> what's going on there? unfortunately i don't really have a lot of time
> to look into this atm ...
>

To come back to your issue, I think the Jamfile needs some fixes. I will 
give a try tonight and probably make a PR, if this sounds ok for you.

Best,
Raffi