Re: [boost] [test] Trunk broken: What happened to test_exec_monitor?

Subject: Re: [boost] [test] Trunk broken: What happened to test_exec_monitor?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-10-03 12:37:09

On Mon, Oct 3, 2011 at 12:03 PM, John Maddock <boost.regex_at_[hidden]> wrote:
>>> Testing on Trunk is apparently broken as the test_exec_monitor target has
>>> been removed from Boost.Test Trunk as of revision #74642.
>>
>> Test Execution Monitor has been deprecated for more than 5 years I believe
>> (since 1.34). I do not believe it's being used anywhere but internally in
>> boost.
>>
>>> A quick grep shows 22 Jamfiles and over 200 targets dependent upon this.
>>
>> To switch to test framework you really only need to change 2 lines:
>>
>> #include <boost/test/included/test_execution_monitor.hpp>
>> to
>> #include <boost/test/included/unit_test.hpp>
>>
>> and
>>
>> int test_main()
>> to
>> BOOST_AUTO_TEST_CASE(test_main)
>>
>> If no one mind I can go ahead and apply these.
>
> I'm not sure if it's that simple - a quick grep shows 815 files with a
> test_main.  What should have happened is that:
>
> * You would announce loud and clear that this feature was going to be
> removed, and then.
> * Work with library authors to remove all uses of this feature and verify
> that nothing is broken in the process.
> * Merge the changes (and only these changes) to the release branch once
> everyone is happy.
> * Only when all uses of the feature have been removed, can the feature
> actually be removed from Trunk.
>
> Any other procedure is sure to cause chaos, not only to Trunk, but all over
> again to the Release branch if we're not *very* careful.
>
> So I think I'd like to see either:
>
> 1) This change is reverted, and the procedure above followed, or:
> 2) The test_exec_monitor is reinstated
>
> Option (2) might be easier - test_exec_monitor could be an alias for the
> unit test lib, and the headers could just declare an auto-unit-test case
> that calls test_main?
>
> Whatever happens, the changes need to be verified as actually fixing the
> problem before being committed, and since the schedule for the next release
> has been announced we need to see this fixed ASAP.  We simply can't afford a
> couple of weeks of thrashing around before Trunk is stable again.

Gennadiy, please revert all of your changes. This mess needs to be
cleared up right away.

Wholesale breakage of trunk isn't acceptable anytime, much less this
late in a release cycle.

--Beman