Re: [Boost-testing] best way to mark up test that only pass with C++0x

Subject: Re: [Boost-testing] best way to mark up test that only pass with C++0x
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-29 17:30:13

Le 29/09/11 22:18, Eric Niebler a écrit :
> On 9/28/2011 4:45 AM, Vicente J. Botet Escriba wrote:
>> Le 26/09/11 03:42, Eric Niebler a écrit :
>>> On 9/25/2011 6:01 PM, Rene Rivera wrote:
>>>> On 9/25/2011 3:15 PM, Eric Niebler wrote:
>>>>> I'm going to be adding tests that rely on 0x features. These tests will
>>>>> fail on non-0x compilers. What's the best way to handle this?
>>>>>
>>>>> I don't want to no-op the tests because then they'll appear to be
>>>>> passing in the grid. But there doesn't seems to be a way to say, "I
>>>>> want
>>>>> to mark these tests as "expected fail" except on 0x toolsets. I can't
>>>>> even reliably look for "_0x" in the toolset name because (for example)
>>>>> the tests should pass on msvc-10.0, which has no "_0x" in the name.
>>>>>
>>>>> Do I need to exhaustively list each and every toolset for which the
>>>>> failure is expected (which would be almost all of them)?
>>>> Doesn't seem that bad to just mark them all, generically, as "expected
>>>> fail". As it just means that on the c++11 compilers you'll get an
>>>> "unexpected success", hence still a success, and the rest will just get
>>>> ignored.
>>> OK, I'll do that.
>>>
>>> I imagine this issue will be cropping up quite a bit in the future. It
>>> would be nice to have a better solution. Thoughts? Ideally, we'd have it
>>> integrated with Boost.Config somehow, so that I could mark a test as
>>> expected fail iff (BOOST_NO_DECLTYPE || BOOST_NO_RVALUE_REFERENCES), for
>>> instance. Is this possible?
>>>
>> I guess that we can run the tests conditionally, so if we were able to
>> check for C++0x mode we could see a white cell for these compilers,
>> meaning the test is not applicable.
> How would a white cell be different than an expected failure?
There is no real difference, just that you have another tool that allow 
you to state if a test can be run or not.
>
>> I propose that we add a feature
>> standard that could take the values 98 and 11. The build system will set
>> this feature to the correct value in cases the compiler only support one
>> of them.
> Is msvc-10 a C++11 compiler? It supports some 11 features but not
> others. I think this is too coarse-grained.
You are right, there is no C++11 compliant compiler. But I'm sure this 
will help to reduce the used compilers used if we start to make 
libraries or tests that need C++C11 features.
>
>> In addition it could add the needed compiler flags with
>> compiles supporting several versions.
> Not sure what this means.
>
Sorry, I was not enough clear. What I meant is that if we define a 
Boost.Build feature for stating the language level, the build system 
could add the cxx_flasg to choose the level, as for example 
<cxxflags>-std=c++0x for gcc.

Best,
Vicente