Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-05 17:46:32


At 11:00 AM 8/5/2002, Douglas Gregor wrote:

>On Monday 05 August 2002 10:28 am, Beman Dawes wrote:
>> Looking at it today, we see that yesterday's function changes broke
>> function_test for several compilers, and some integer related warnings
>got
>> cleared (in several tests).
>
>Will there be any notion of an expected failure in this testing system?
>I'd really like to make function_test an expected failure for compilers
that
>
>can't handle it instead of hiding the problems behind #ifdefs (there's no

>feasible workaround AFAICT). How's a vendor or user ever to know that
>there's
>a problem if we slip an #ifdef around the things that don't work?

There was some talk of that at one time, but I don't remember any
conclusion being reached.

It would be easy for the program that generates the Status Reporting to
look in a file for a list of test/compiler/version[/platform] combinations
that need to be reported with some special status. The file could live in
CVS, so developers can maintain it for their own tests. IOW, it wouldn't
be the responsibility of the people who run the regression tests to figure
out when it applied.

Brainstorming a bit, let's say this is called the broken-compiler file. If
test/compiler/version[/platform] names match the current cell, it will be
reported as "Broken" or similar, with a link to a description that says
something like:

"This compiler fails to comply with the C++ standard in some aspect
required to pass this test. The developer knows of no practical
workaround. Complain to the compiler vendor!"

Is that what you had in mind?

>> I consider the click-through to the compiler, linker, and run messages
to
>> be a great success. It really makes it easy to inspect failures.
>
>It's very nice! One little nitpick: '<' seems to be replaced with "&lt"
>instead of "&lt;" in the -links document.

Duh! Fixed. Thanks! Note that it may take awhile for that fix to propagate
to all the .xml files the -links doc is drawn from.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk