Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 74.125.46.28 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding:sender;
        b=R46KNZzO4ueVBZ9ZHdUEyZA8+Km921LiKXcTge1ufHc8SSrDotX989jwiFklWZj3KJ
         ARQYhxAN19RNIxOVxg4jUhA3gSroqSSyx4AGIRJGLdR5kJ80P9dR29FQ2ioHKU6BXaQ0
         RAtjaffcnBTNaJR380B/7bX4xGlh7/BoUwU9o=
Message-ID: <48697E6C.20104@roguewave.com>
Date: Mon, 30 Jun 2008 18:46:36 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: C++ 0x testing
References: <486955F9.3080205@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0609@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0609@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Monday, June 30, 2008 3:54 PM
>> To: dev@stdcxx.apache.org
>> Subject: C++ 0x testing
>>
>> 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().
>>
>> 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__.
>>
>> 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?

> 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

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). 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.

Martin