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 >
