Re: [boost] [predef] Using predef-check on 'develop' problem

Subject: Re: [boost] [predef] Using predef-check on 'develop' problem
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-25 23:29:12

On 5/25/2015 10:51 PM, Aparna Kumta wrote:
> On 05/25/15 19:22, Edward Diener wrote:
>> On 5/25/2015 9:43 PM, Aparna Kumta wrote:
>>> On 05/25/15 18:25, Edward Diener wrote:
>>>> On 5/18/2015 10:57 PM, Rene Rivera wrote:
>>>>> On Mon, May 18, 2015 at 9:38 PM, Rene Rivera <grafikrobot_at_[hidden]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, May 18, 2015 at 8:57 PM, Edward Diener
>>>>>> <eldiener_at_[hidden]>
>>>>>> wrote:
>>>>>>
>>>>>>> On 5/15/2015 4:38 PM, Rene Rivera wrote:
>>>>>>>
>>>>>>>> On Fri, May 15, 2015 at 3:31 PM, Edward Diener
>>>>>>>> <eldiener_at_[hidden]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>   In a jam file I have for a run test a predef-check which looks
>>>>>>>> like:
>>>>>>>>>
>>>>>>>>> run test_variadic_macro.cpp : : : [ predef-check
>>>>>>>>> "BOOST_COMP_GNUC >=
>>>>>>>>> 4.3"
>>>>>>>>> "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ;
>>>>>>>>>
>>>>>>>>> When running on QNX with the gcc version greater than 4.3 I would
>>>>>>>>> expect
>>>>>>>>> that -std=c++0x would not be added as a C++ compile parameter
>>>>>>>>> to the
>>>>>>>>> run.
>>>>>>>>> Yet it is being added to the run.
>>>>>>>>>
>>>>>>>>> Another test confirms that BOOST_OS_QNX is indeed being set to a
>>>>>>>>> non-zero
>>>>>>>>> value.
>>>>>>>>>
>>>>>>>>> Is there a bug in predef-check ? Am I using it incorrectly ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> It looks like a bug to me.. I'll investigate further tonight.
>>>>>>>>
>>>>>>>>
>>>>>>> What I am also seeing, besides the QNX problem, is that for the
>>>>>>> Android
>>>>>>> OS 'develop' tests, using the same predef-check as above, both
>>>>>>> conditions
>>>>>>> are true, yet the -std=c++0x is not on the command line of the
>>>>>>> tests.
>>>>>>
>>>>>>
>>>>>> FYI.. I haven't stopped working on fixing this. And I have an almost
>>>>>> working resolution.
>>>>>>
>>>>>
>>>>> And it's done, and checked into the predef develop branch. I need to
>>>>> update
>>>>> and regenerate docs before I can merge to master though. So things
>>>>> will
>>>>> only start working on the develop super-project.
>>>>
>>>> I have discovered a problem with predef in the 'develop' regression
>>>> tests at
>>>> http://www.boost.org/development/tests/develop/developer/summary.html
>>>> for the SunOS operating system and Oracle ( aka Sun ) C++.
>>>>
>>>> If you look at the predef info_as_cpp tests, such as at
>>>> http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP1-ARM-boost-bin-v2-libs-predef-test-info_as_cpp-test-qcc-4-4-2_arm-debug-debug-symbols-off.html,
>>>>
>>>> you will see that no compiler is being detected.
>>>>
>>>> Yet if you look at my VMD test, called test_variadic_macro, at
>>>> http://www.boost.org/development/tests/develop/developer/output/oracle-intel-S2-stlport4-boost-bin-v2-libs-vmd-test-test_variadic_macro-test-sun-stlport4-release-threading-multi.html,
>>>>
>>>> you can see that I am picking up that '__SUNPRO_CC' is defined.
>>> The error I see in this case is
>>>
>>> ../libs/vmd/test/test_variadic_macro.cxx(25): No variadic macro support:
>>> __SUNPRO_CC defined. in function '(unknown)'
>>>
>>> Oracle Solaris Studio does support variadic macros.
>>> In libs/preprocessor/include/boost/preprocessor/config/config.hpp
>>> line# 73-77, seems incorrect for SUNPRO_CC and
>>> BOOST_PP_VARIADICS should be set to 1.
>>>
>>> 73  # define BOOST_PP_VARIADICS_MSVC 0
>>> 74  # if !defined BOOST_PP_VARIADICS
>>> 75  #    /* variadic support explicitly disabled for all untested
>>> compilers */
>>> 76  #    if defined __GCCXML__ || defined __CUDACC__ || defined
>>> __PATHSCALE__ || defined __DMC__ || de
>>> fined __CODEGEARC__ || defined __BORLANDC__ || defined __MWERKS__ ||
>>> defined __SUNPRO_CC || defined __HP_a
>>> CC && !defined __EDG__ || defined __MRC__ || defined __SC__ || defined
>>> __IBMCPP__ || defined __PGI
>>> 77  #        define BOOST_PP_VARIADICS 0
>>>
>>> Should I submit a PR for this change?
>>
>> No need. I am aware of it. I need to determine the value of
>> __SUNPRO_CC or above which can support variadic macros, and then I
>> will make the change and update it in the preprocessor library. I am
>> pretty sure it is version 12.3 and above, and I know the __SUNPRO_CC
>> value for that version (0x5120).
> Variadic macros have been supported for a while.
> The only compilers that don't support variadic macros are End Of Service
> Life, so we don't  need to check for the value.

Nonetheless I want to be conservative about this, as it might change the 
functionality of users of past versions of Oracle C++ who have used 
Boost PP in their macro programming. Remember that Boost PP can still 
function without variadic macro support and it has been around for quite 
awhile. Whereas VMD is a new library which hasn't been used in the past 
since the next Boost release will be the first, and it requires variadic 
macro support. Furthermore we haven't been regression testing Oracle C++ 
in the past, whether with Boost PP or anything else, so I am loath to 
make a radical change with Boost PP and older versions of Oracle C++ ( 
Sun C++ in the past ).

What I am going to do is change the code above so that variadic support 
is automatically turned off with Oracle C++ only for versions below 
12.3. If anyone running a version of Oracle C++ below 12.3 wants to use 
VMD he can still force variadic macro support by defining 
BOOST_PP_VARIADICS=1. I have chosem 12.3 since it appears to be the 
first release that supports C++11 through a 'std=' option and variadic 
macro support is part of C++11 although many compilers previosuly 
supported it from the C99 standard.

I also must pay attention to the Boost PP tests for your setup so that 
my change does not cause any problems there.

I also see that there is no information about the version of Oracle C++ 
you are tesing in the regression tests. Can this be added somewhere so 
it can be seen ? For most other compilers it gives the name and version 
of the compiler.