Re: [boost] Re: Experimental audience-targeted regression results

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-06-24 09:15:44

Aleksey Gurtovoy wrote:
> Peter Dimov wrote:
>> Aleksey Gurtovoy wrote:
>>>
>>> Well, check out the latest developer report -
>>>
>> http://boost.sourceforge.net/regression-logs/developer_summary
>> _page.html!
>>
>> Intel-7.1 is misconfigured. ADL is disabled but
>> BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is not set. That is why
>> intrusive_ptr_test and shared_ptr_test fail.
>
> Well, we didn't do anything special to mis-configure it ;),

Beman did:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/config/compiler/intel.hpp.diff?r1=1.24&r2=1.25

> besides
> choosing MSVC 6 compatibility mode (during the setup, as opposite to
> MSVC 7.0 one). Any ideas what's the right way to fix that?

I'm not sure. It seems to be that the above fix breaks the common Intel
configuration. On the other hand, some people use Intel precisely because
they need the additional features.

I think that the "right way(tm)" to handle the situation where a compiler
offers a configuration option affecting conformance but does not predefine a
macro to indicate that is for us to simply "predefine" such a macro and
include it wherever we include the option.

IOW, when a toolset specifies -Qoption,cpp,--arg_dep_lookup it should also
specify BOOST_HAS_ARGUMENT_DEPENDENT_LOOKUP that will override its
BOOST_NO_* counterpart (possibly in suffix.hpp).

But I'm neither a config expert nor a build expert. ;-)

>> Beman's approach, where unexpected failures were automatically
>> determined by comparing the current run with a previous run, seems to
>> cope better with this scenario, and requires no manual input.
>
> Does it? What if the previous run was a total failure - what the next
> one is going to show?

Nothing will go wrong; it's only pass->fail transitions that are emphasized.
False pass->fail transitions can only happen for compile-fail/link-fail
tests that aren't that significant.

> IMO it can work only if you have a trusted
> snapshot of what is considered a "good" CVS state and you update it
> "pessimistically" - that is, remove the expected failures that are now
> passing and leave everything else intact - automatically, of course.
> And that's exactly what we are going to do.

I didn't realize that the plan was to automatically manage the expected
failures.