stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: C++ 0x testing
Date Tue, 01 Jul 2008 01:22:20 GMT
 

Martin Sebor wrote:
>
>Eric Lemings wrote:
>>  
>> 
>>Martin Sebor wrote:
>>>
>>> Unless I'm missing something, C++ 0x testing is currently disabled
>>> in nightly builds. I.e., because tests for the newly added C++ 0x
>>> features are guarded by the _RWSTD_NO_CXX_0X macro and because
>>> _RWSTD_EXT_CXX_0X is not #defined, the tests are compiled into
>>> what essentially amounts an empty main().

Yes.

>>> With type traits and tuple being nearly done, I think it's time
>>> to start exercising these and any other new components in nightly
>>> builds. One approach that might be easily implementable at least
>>> for gcc is the one suggested in a recent thread: for 4.3.x, add 
>>> -std=gnu++0x to the set of compiler options for gcc 4.3 and
>>> beyond, and make _RWSTD_EXT_CXX_0X synonymous with gcc's
>>> __GXX_EXPERIMENTAL_CXX0X__.

This should be okay.

>>>
>>> Is there a better approach? I'd like to get things set up
>>> sometime this week.
>> 
>> Rather than hard-code the flags, I suggest a command-line make
>> definition; e.g. make _RWSTD_EXT_CXX_0X=1 ...
>> 
>> I thought this is the way it was originally proposed.
>
>I'm not sure where the _RWSTD_EXT_CXX_0X macro came from or why
>C++ 0x is disabled by default even for compilers that it works
>with. I remember suggesting _RWSTD_NO_EXT_CXX_0X but not
>_RWSTD_EXT_CXX_0X. Of course, it's entirely possible that
>I forgot. Travis, what's your insight into this?

The discussion that I remember (I should check the archives) we said
that we wanted to disable the c++0x extensions by default, but wanted to
provide a way to enable them. We had also said that we wanted to enable
them by default at some time in the future. This was the primitive
method that I came up with to allow for this while still allowing us to
do manual builds.

I don't rally see a huge advantage to doing it the way I have it now,
and I'm completely open to removing the _RWSTD_EXT_CXX_0X macro and
using compiler specific macros or even config tests to see if we can
safely attempt to use the c++0x extensions.

>> Anyways,
>> the gcc.config flag appends the appropriate compiler flags and
>> defines only if this make variable is defined; e.g.
>> 
>> 	ifeq ($(_RWSTD_EXT_CXX_0X),1)
>> 	    CXXFLAGS += -std=gnu++0x -D_RWSTD_EXT_CXX_0X
>> 	endif
>

This would work also. This is what I was expecting to have to do until
we opted to enable the extensions by default (for 5.0.0).

>I'm suggesting we unconditionally enable it on 4.3.x in builds
>with gcc 4.3 (and all other compilers where it's intended to
>be tested).

Just gcc-4.3 and msvc-8.0 right now. I haven't bothered to work with any
other platforms because it seems the traits implementation is still in
limbo.

>IIUC, the approach outlined above won't help us test
>the implementation in nightly builds because it'll still leave
>C++ 0x disabled unless we also change the buildntest script to
>define the make variable the way you show. If we were to take
>this approach I don't see the advantage over simply setting
>CXXOPTS=-std=gnu++0x instead. It seems to me that most users
>are more likely to be familiar and comfortable with using
>compiler options than with #defining our config macros.
>

If we are absolutely confident that we won't introduce any
incompatibilities, then I don't see any serious problems with doing
this. The only issue I can think of is that the library may configure
differently with -std=gnu++0x and the users could want build without it.
Doing it this way would make it more difficult to remove the flag.

>Martin
>

Mime
View raw message