On 5/15/2015 4:38 PM, Rene Rivera wrote:

On Fri, May 15, 2015 at 3:31 PM, Edward Diener 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.

On Mon, May 18, 2015 at 9:38 PM, Rene Rivera wrote:

On Mon, May 18, 2015 at 8:57 PM, Edward Diener wrote:

...

On 5/15/2015 4:38 PM, Rene Rivera wrote:

...

On Fri, May 15, 2015 at 3:31 PM, Edward Diener 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. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 5/18/2015 10:57 PM, Rene Rivera wrote:

On Mon, May 18, 2015 at 9:38 PM, Rene Rivera wrote:

...

On Mon, May 18, 2015 at 8:57 PM, Edward Diener wrote:

...

On 5/15/2015 4:38 PM, Rene Rivera wrote:

...

On Fri, May 15, 2015 at 3:31 PM, Edward Diener 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.

Your change is now working correctly for me on the QNX 'develop' regression tests for VMD. The Android regression test results are started a number of days earlier than the date on the regression test itself so that it will still be a few days before I can see if your change fixes the problems running VMD 'develop' regression tests for Android.

On Mon, May 25, 2015 at 8:25 PM, Edward Diener wrote:

If you look at the predef info_as_cpp tests, such as at

http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP..., you will see that no compiler is being detected.

Ah.. I see: BOOST_COMP_GNUC = 40400002 (4,4,2) | Gnu GCC C/C++ Maybe you meant this link: < http://www.boost.org/development/tests/develop/developer/output/oracle-intel...

??

Yet if you look at my VMD test, called test_variadic_macro, at http://www.boost.org/development/tests/develop/developer/output/oracle-intel..., you can see that I am picking up that '__SUNPRO_CC' is defined.

Yet if '__SUNPRO_CC' is defined then predef should be picking that up and setting BOOST_COMP_SUNPRO to the compiler being detected.

Right. Along with that problem is that in my VMD tests, aside from the

test_variadic_macro test, I have the predef-check as specified in my OP above. Yet this is being triggered for the SunOS operating system tests when clearly the compiler is not BOOST_COMP_GNUC, and '-std=c++0x' is erroneously being added for the VMD tests which causes them all to fail because the tests are being run with '-compat=5 -library=stlport4'. So here again, with SunOS and Oracle ( aka Sun ) C++, predef does not appear to be working correctly.

Well, let me fix the first problem. Perhaps it's a side effect of the Sun compiler not being detected. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 5/25/2015 9:34 PM, Rene Rivera wrote:

On Mon, May 25, 2015 at 8:25 PM, Edward Diener wrote:

...

If you look at the predef info_as_cpp tests, such as at

...

http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP..., you will see that no compiler is being detected.

Ah.. I see: BOOST_COMP_GNUC = 40400002 (4,4,2) | Gnu GCC C/C++

Maybe you meant this link: < http://www.boost.org/development/tests/develop/developer/output/oracle-intel...

...

??

...

Yet if you look at my VMD test, called test_variadic_macro, at http://www.boost.org/development/tests/develop/developer/output/oracle-intel..., you can see that I am picking up that '__SUNPRO_CC' is defined.

Yet if '__SUNPRO_CC' is defined then predef should be picking that up and setting BOOST_COMP_SUNPRO to the compiler being detected.

Right.

Along with that problem is that in my VMD tests, aside from the

...

test_variadic_macro test, I have the predef-check as specified in my OP above. Yet this is being triggered for the SunOS operating system tests when clearly the compiler is not BOOST_COMP_GNUC, and '-std=c++0x' is erroneously being added for the VMD tests which causes them all to fail because the tests are being run with '-compat=5 -library=stlport4'. So here again, with SunOS and Oracle ( aka Sun ) C++, predef does not appear to be working correctly.

Well, let me fix the first problem. Perhaps it's a side effect of the Sun compiler not being detected.

I appreciate your efforts to fix this problem. As a side note on the Android tests using gcc, both predef and my own test_variadic_macro test are finding that gcc is being detected but the predef-check statement mentioned in my OP is also not adding '-std=c++0x' to the command line there.

On 5/26/2015 1:02 PM, Rene Rivera wrote:

On Tue, May 26, 2015 at 9:48 AM, Edward Diener wrote:

...

On 5/25/2015 9:34 PM, Rene Rivera wrote:

...

On Mon, May 25, 2015 at 8:25 PM, Edward Diener wrote:

...

If you look at the predef info_as_cpp tests, such as at

...

http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP... , you will see that no compiler is being detected.

Ah.. I see: BOOST_COMP_GNUC = 40400002 (4,4,2) | Gnu GCC C/C++

Maybe you meant this link: <

http://www.boost.org/development/tests/develop/developer/output/oracle-intel...

...

??

Yet if you look at my VMD test, called test_variadic_macro, at

...

http://www.boost.org/development/tests/develop/developer/output/oracle-intel... , you can see that I am picking up that '__SUNPRO_CC' is defined.

Yet if '__SUNPRO_CC' is defined then predef should be picking that up and setting BOOST_COMP_SUNPRO to the compiler being detected.

Right.

Along with that problem is that in my VMD tests, aside from the

...

test_variadic_macro test, I have the predef-check as specified in my OP above. Yet this is being triggered for the SunOS operating system tests when clearly the compiler is not BOOST_COMP_GNUC, and '-std=c++0x' is erroneously being added for the VMD tests which causes them all to fail because the tests are being run with '-compat=5 -library=stlport4'. So here again, with SunOS and Oracle ( aka Sun ) C++, predef does not appear to be working correctly.

Well, let me fix the first problem. Perhaps it's a side effect of the Sun compiler not being detected.

I appreciate your efforts to fix this problem.

As a side note on the Android tests using gcc, both predef and my own test_variadic_macro test are finding that gcc is being detected but the predef-check statement mentioned in my OP is also not adding '-std=c++0x' to the command line there.

FYI..

a) I just don't see how the sunpro detection is not working. Logic looks correct. But I'll keep scratching head and looking at the code :-\

b) I can't replicate your original problem either. I have a test that has the exact same condition and it works to add two compile options as needed. It's the predef/check_value test, for which you can compare the clang vs. gcc output here https://travis-ci.org/boostorg/predef. And I'm waiting on the full Boost test to cycle to check other platforms.

Is there any way you can add this test to the Boost regression tests ? I don't run any tests personally under Android or QNX OSs, but I can't help thinking that this may be a Boost Build problem or an OS problem if it is not a predef problem. In my VMD jamfile I have at the top: import ../../predef/check/predef : check require : predef-check predef-require ; Does that look right ? The line in my VMD tests for, let's say, the test_doc_empty.cpp test is: [ run test_doc_empty.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ] Does that look right ? Yet on the Android regression test for this at http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apileve... I see this command line: "/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-develop/test/develop/regression/armeabi/gcc-4.9/g++-4.9" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic -fPIC -pedantic-errors -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/home/cislave/.crystax/ci-boost/regression/android-21-armeabi-develop/test/develop/regression/armeabi/test/results/boost/bin.v2/libs/vmd/test/test_doc_empty.test/gcc-4.9/release/target-os-android/threading-multi/test_doc_empty.o" "../libs/vmd/test/test_doc_empty.cpp" and there is obviously no '-std=c++0x' being added there. So I am as baffled as you are. I can ask the Android testers to manually add the '-std=c++0x' to the test if there is a way for them to do it just for the VMD tests as part of there regression tests.

On Mon, May 25, 2015 at 8:34 PM, Rene Rivera wrote:

On Mon, May 25, 2015 at 8:25 PM, Edward Diener wrote:

...

If you look at the predef info_as_cpp tests, such as at

...

http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP..., you will see that no compiler is being detected.

Ah.. I see: BOOST_COMP_GNUC = 40400002 (4,4,2) | Gnu GCC C/C++

Maybe you meant this link: < http://www.boost.org/development/tests/develop/developer/output/oracle-intel...

...

??

...

Yet if you look at my VMD test, called test_variadic_macro, at http://www.boost.org/development/tests/develop/developer/output/oracle-intel..., you can see that I am picking up that '__SUNPRO_CC' is defined.

Yet if '__SUNPRO_CC' is defined then predef should be picking that up and setting BOOST_COMP_SUNPRO to the compiler being detected.

Right.

Along with that problem is that in my VMD tests, aside from the

...

test_variadic_macro test, I have the predef-check as specified in my OP above. Yet this is being triggered for the SunOS operating system tests when clearly the compiler is not BOOST_COMP_GNUC, and '-std=c++0x' is erroneously being added for the VMD tests which causes them all to fail because the tests are being run with '-compat=5 -library=stlport4'. So here again, with SunOS and Oracle ( aka Sun ) C++, predef does not appear to be working correctly.

Well, let me fix the first problem. Perhaps it's a side effect of the Sun compiler not being detected.

OK, this seems to be fixed now. Took a while for the testers to get to testing it. Can you verify that the Predef check issues are also taken care of? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Mon, Jun 1, 2015 at 4:35 PM, Edward Diener wrote:

On 6/1/2015 2:41 PM, Rene Rivera wrote:

...

On Mon, May 25, 2015 at 8:34 PM, Rene Rivera wrote:

...

On Mon, May 25, 2015 at 8:25 PM, Edward Diener wrote:

...

If you look at the predef info_as_cpp tests, such as at

...

http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP... , you will see that no compiler is being detected.

Ah.. I see: BOOST_COMP_GNUC = 40400002 (4,4,2) | Gnu GCC C/C++

Maybe you meant this link: <

http://www.boost.org/development/tests/develop/developer/output/oracle-intel...

...

??

Yet if you look at my VMD test, called test_variadic_macro, at

...

http://www.boost.org/development/tests/develop/developer/output/oracle-intel... , you can see that I am picking up that '__SUNPRO_CC' is defined.

Yet if '__SUNPRO_CC' is defined then predef should be picking that up and setting BOOST_COMP_SUNPRO to the compiler being detected.

Right.

Along with that problem is that in my VMD tests, aside from the

...

test_variadic_macro test, I have the predef-check as specified in my OP above. Yet this is being triggered for the SunOS operating system tests when clearly the compiler is not BOOST_COMP_GNUC, and '-std=c++0x' is erroneously being added for the VMD tests which causes them all to fail because the tests are being run with '-compat=5 -library=stlport4'. So here again, with SunOS and Oracle ( aka Sun ) C++, predef does not appear to be working correctly.

Well, let me fix the first problem. Perhaps it's a side effect of the Sun compiler not being detected.

OK, this seems to be fixed now. Took a while for the testers to get to testing it. Can you verify that the Predef check issues are also taken care of?

Your June 1 predef changes have not been picked up by the latest VMD tests for Android and Oracle C++ yet. Should previous changes have fixed the problem I was seeing in those tests ? If not I still have to wait until the Android and Oracle C++ tests with your June 1 changes cycle. The VMD tests on QNX are now working correctly even though your June 1 changes were not picked up there yet.

It wasn't the June 1st changes that I refer to that makes this < http://www.boost.org/development/tests/develop/developer/output/oracle-intel-S2-stlport4-boost-bin-v2-libs-predef-test-info_as_cpp-test-sun-stlport4-release-threading-multi.html> work correctly for SUNPRO. It was actually this change < https://github.com/boostorg/predef/commit/58c23226b1ebed2579d0f3296faaff958f...

.

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 6/1/2015 5:43 PM, Rene Rivera wrote:

On Mon, Jun 1, 2015 at 4:35 PM, Edward Diener wrote:

...

On 6/1/2015 2:41 PM, Rene Rivera wrote:

...

On Mon, May 25, 2015 at 8:34 PM, Rene Rivera wrote:

...

On Mon, May 25, 2015 at 8:25 PM, Edward Diener wrote:

...

If you look at the predef info_as_cpp tests, such as at

...

http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP... , you will see that no compiler is being detected.

Ah.. I see: BOOST_COMP_GNUC = 40400002 (4,4,2) | Gnu GCC C/C++

Maybe you meant this link: <

http://www.boost.org/development/tests/develop/developer/output/oracle-intel...

...

??

Yet if you look at my VMD test, called test_variadic_macro, at

...

http://www.boost.org/development/tests/develop/developer/output/oracle-intel... , you can see that I am picking up that '__SUNPRO_CC' is defined.

Yet if '__SUNPRO_CC' is defined then predef should be picking that up and setting BOOST_COMP_SUNPRO to the compiler being detected.

Right.

Along with that problem is that in my VMD tests, aside from the

...

test_variadic_macro test, I have the predef-check as specified in my OP above. Yet this is being triggered for the SunOS operating system tests when clearly the compiler is not BOOST_COMP_GNUC, and '-std=c++0x' is erroneously being added for the VMD tests which causes them all to fail because the tests are being run with '-compat=5 -library=stlport4'. So here again, with SunOS and Oracle ( aka Sun ) C++, predef does not appear to be working correctly.

Well, let me fix the first problem. Perhaps it's a side effect of the Sun compiler not being detected.

OK, this seems to be fixed now. Took a while for the testers to get to testing it. Can you verify that the Predef check issues are also taken care of?

Your June 1 predef changes have not been picked up by the latest VMD tests for Android and Oracle C++ yet. Should previous changes have fixed the problem I was seeing in those tests ? If not I still have to wait until the Android and Oracle C++ tests with your June 1 changes cycle. The VMD tests on QNX are now working correctly even though your June 1 changes were not picked up there yet.

It wasn't the June 1st changes that I refer to that makes this < http://www.boost.org/development/tests/develop/developer/output/oracle-intel-S2-stlport4-boost-bin-v2-libs-predef-test-info_as_cpp-test-sun-stlport4-release-threading-multi.html> work correctly for SUNPRO. It was actually this change < https://github.com/boostorg/predef/commit/58c23226b1ebed2579d0f3296faaff958f...

Corrected reply: Something is still wrong then. In my VMD jamfile a line like: [ run test_after_array_elem.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ] is still adding '-std=c++0x' to the command line for the SunOS oracle-intel-S2-stlport4 test even though BOOST_COMP_GNUC is 0. You can see that at http://www.boost.org/development/tests/develop/developer/output/oracle-intel.... And the reason I know that it is the VMD jamfile adding the '-std=c++0x' and not the regression tester is that I have this line in the VMD jamfile: [ run test_variadic_macro.cpp ] and if you look at http://www.boost.org/development/tests/develop/developer/output/oracle-intel... you will see that '-std=c++0x' is not being added to the command line. Yet in the QNX 'develop' VMD regression tests, where BOOST_COMP_GNUC >= 4.3 and BOOST_OS_QNX is not 0, the '-std=c++0x' is correctly not being added to the command line for a line like: [ compile-fail test_doc_empty_fail2.cpp : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ] You can see this for a test that fails at http://www.boost.org/development/tests/develop/developer/output/NA-QNX650-SP.... So in the QNX case the predef-check is working but for SunOS there is still a problem.

On Fri, Jun 5, 2015 at 9:42 PM, Edward Diener wrote:

I think I know what is wrong in the predef-check functionality. In my VMD jamfile the use of predef-check, for any given compile or run rule, looks like:

[ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ]

Yes.. What I am seeing is that except on QNX, where "BOOST_OS_QNX != 0", the

'-std=c++0x' is always being added as a C++ compiler flag to the command line.

This initially suggests to me that you are treating more than one quoted predef definition as an OR gate rather than an AND gate. But note that on QNX, where where "BOOST_OS_QNX != 0" and "BOOST_COMP_GNUC >= 4.3" is true, the '-std=c++0x' is not being added. So your logic seems to be that as you go through multiple predef definitions once you hit a 'true' condition you choose the 'true' path as long as no 'false' conditions follow it, else you choose the 'false' path.

Please see if you can fix this given this clue about how predef-check is working for the VMD regression tests on various platforms/compilers.

I don't know if it helped but I did a change to one of the tests I do to completely cover all the Venn variations of the binary and expression. I changed my test to this: [ run check_value.cpp : : : <test-info>always_show_run_output [ predef-check "BOOST_COMP_CLANG > 0" "BOOST_OS_LINUX == 0" : : <cxxflags>-DCHECK_VALUE=true : <cxxflags>-DCHECK_VALUE=false ] ] And then observed the results on Travis-CI [1], Appveyor [2], and my OSX dev laptop. The results are as follows: === Performing configuration checks - BOOST_OS_MACOS : no - BOOST_COMP_CLANG > 0 : yes - BOOST_OS_LINUX == 0 : no ...found 53 targets... [...] ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_CLANG = 30400002 (3,4,2) | Clang BOOST_COMP_GNUC_EMULATED = 40200001 (4,2,1) | Gnu GCC C/C++ BOOST_COMP_LLVM_EMULATED = 1 (0,0,1) | LLVM BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_C_GNU = 21500000 (2,15,0) | GNU BOOST_LIB_STD_GNU = 420300001 (42,3,1) | GNU BOOST_OS_LINUX = 1 (0,0,1) | Linux BOOST_OS_UNIX = 1 (0,0,1) | Unix Environment [...] testing.capture-output ../../bin/predef/test/check_value.test/clang-linux-3.4.2/debug/check_value.run ====== BEGIN OUTPUT ====== CHECK_VALUE == 0 [...] === === Performing configuration checks - BOOST_OS_MACOS : no - BOOST_COMP_CLANG > 0 : no - BOOST_OS_LINUX == 0 : no ...found 53 targets... [...] ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_GNUC = 40700003 (4,7,3) | Gnu GCC C/C++ BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_C_GNU = 21500000 (2,15,0) | GNU BOOST_LIB_STD_GNU = 430400021 (43,4,21) | GNU BOOST_OS_LINUX = 1 (0,0,1) | Linux BOOST_OS_UNIX = 1 (0,0,1) | Unix Environment [...] testing.capture-output ../../bin/predef/test/check_value.test/gcc-4.7/debug/check_value.run ====== BEGIN OUTPUT ====== CHECK_VALUE == 0 [...] === === Performing configuration checks - BOOST_OS_MACOS : no - BOOST_COMP_CLANG > 0 : no - BOOST_OS_LINUX == 0 : yes ...found 63 targets... [...] ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_32 = 60000000 (6,0,0) | Intel x86-32 BOOST_COMP_MSVC = 90030729 (9,0,30729) | Microsoft Visual C/C++ BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_STD_DINKUMWARE = 50500000 (5,5,0) | Dinkumware BOOST_OS_WINDOWS = 1 (0,0,1) | Microsoft Windows BOOST_PLAT_WINDOWS_DESKTOP = 1 (0,0,1) | Windows Desktop [...] testing.capture-output ..\..\bin\predef\test\check_value.test\msvc-9.0\debug\threading-multi\check_value.run 1 file(s) copied. ====== BEGIN OUTPUT ====== CHECK_VALUE == 0 [...] === === Performing configuration checks - BOOST_OS_MACOS : yes (cached) - BOOST_COMP_CLANG > 0 : yes (cached) - BOOST_OS_LINUX == 0 : yes ...found 83 targets... [...] ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_CLANG = 60000000 (6,0,0) | Clang BOOST_COMP_GNUC_EMULATED = 40200001 (4,2,1) | Gnu GCC C/C++ BOOST_COMP_LLVM_EMULATED = 1 (0,0,1) | LLVM BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_STD_CXX = 10000101 (1,0,101) | libc++ BOOST_OS_MACOS = 100000000 (10,0,0) | Mac OS [...] testing.capture-output ../../bin/predef/test/check_value.test/clang-darwin-4.2.1/debug/check_value.run ====== BEGIN OUTPUT ====== CHECK_VALUE == 1 [...] === Which summarized means that all the and expression evaluate correctly... "yes" and "no" == 0, "no" and "no" == 0, "no" and "yes == 0, and "yes" and "yes" == 1. Hence the Predef check is working as intended. Some something else must be going on in the case of VMD. [1] https://travis-ci.org/boostorg/predef [2] https://ci.appveyor.com/project/boostorg/predef -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Tue, Jun 9, 2015 at 9:56 PM, Jessica Hamilton < jessica.l.hamilton@gmail.com> wrote:

...

On Fri, Jun 5, 2015 at 9:42 PM, Edward Diener wrote:

...

I think I know what is wrong in the predef-check functionality. In my VMD jamfile the use of predef-check, for any given compile or run rule, looks like:

[ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ]

Yes..

What I am seeing is that except on QNX, where "BOOST_OS_QNX != 0", the

...

'-std=c++0x' is always being added as a C++ compiler flag to the command line.

This initially suggests to me that you are treating more than one quoted predef definition as an OR gate rather than an AND gate. But note that on QNX, where where "BOOST_OS_QNX != 0" and "BOOST_COMP_GNUC >= 4.3" is

On 9 June 2015 at 19:40, Rene Rivera wrote: true,

...

...

the '-std=c++0x' is not being added. So your logic seems to be that as you go through multiple predef definitions once you hit a 'true' condition you choose the 'true' path as long as no 'false' conditions follow it, else you choose the 'false' path.

Please see if you can fix this given this clue about how predef-check is working for the VMD regression tests on various platforms/compilers.

I don't know if it helped but I did a change to one of the tests I do to completely cover all the Venn variations of the binary and expression. I changed my test to this:

[ run check_value.cpp : : : <test-info>always_show_run_output [ predef-check "BOOST_COMP_CLANG > 0" "BOOST_OS_LINUX == 0" : : <cxxflags>-DCHECK_VALUE=true : <cxxflags>-DCHECK_VALUE=false ] ]

Out of curiosity, what happens if you remove the second <cxxflags> variable, and use an #ifndef check, and run again? It's the only difference I can notice between the two examples.

OK.. Did that change. My local OSX test shows "CHECK_VALUE == 1" as expected and correctly. In a few minutes I'll post what the online tests show. But the expectation is that they should all show "CHECK_VALUE == undefined". -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 6/10/2015 12:36 AM, Rene Rivera wrote:

On Tue, Jun 9, 2015 at 10:34 PM, Rene Rivera wrote:

...

On Tue, Jun 9, 2015 at 9:56 PM, Jessica Hamilton < jessica.l.hamilton@gmail.com> wrote:

...

...

On Fri, Jun 5, 2015 at 9:42 PM, Edward Diener wrote:

...

I think I know what is wrong in the predef-check functionality. In my VMD jamfile the use of predef-check, for any given compile or run rule, looks like:

[ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ]

Yes..

What I am seeing is that except on QNX, where "BOOST_OS_QNX != 0", the

...

'-std=c++0x' is always being added as a C++ compiler flag to the command line.

This initially suggests to me that you are treating more than one quoted predef definition as an OR gate rather than an AND gate. But note that on QNX, where where "BOOST_OS_QNX != 0" and "BOOST_COMP_GNUC >= 4.3" is

On 9 June 2015 at 19:40, Rene Rivera wrote: true,

...

...

the '-std=c++0x' is not being added. So your logic seems to be that as you go through multiple predef definitions once you hit a 'true' condition you choose the 'true' path as long as no 'false' conditions follow it, else you choose the 'false' path.

Please see if you can fix this given this clue about how predef-check is working for the VMD regression tests on various platforms/compilers.

I don't know if it helped but I did a change to one of the tests I do to completely cover all the Venn variations of the binary and expression. I changed my test to this:

[ run check_value.cpp : : : <test-info>always_show_run_output [ predef-check "BOOST_COMP_CLANG > 0" "BOOST_OS_LINUX == 0" : : <cxxflags>-DCHECK_VALUE=true : <cxxflags>-DCHECK_VALUE=false ] ]

Out of curiosity, what happens if you remove the second <cxxflags> variable, and use an #ifndef check, and run again? It's the only difference I can notice between the two examples.

OK.. Did that change. My local OSX test shows "CHECK_VALUE == 1" as expected and correctly. In a few minutes I'll post what the online tests show. But the expectation is that they should all show "CHECK_VALUE == undefined".

And the online tests are now done. And indeed they all print out "CHECK_VALUE == undefined".

Feel free to take a look at my VMD tests jamfile. If you see anything you think is wrong I can change it. I don't think it is the jamfile but something having to do with the Android and SunOS operating systems. I realize that I was wrong in thinking that -std=c++0x is always added, annd that this was my mistake.

On 6/16/2015 5:24 PM, Aparna Kumta wrote:

On 06/10/15 03:36, Edward Diener wrote:

...

On 6/10/2015 12:36 AM, Rene Rivera wrote:

...

On Tue, Jun 9, 2015 at 10:34 PM, Rene Rivera wrote:

...

On Tue, Jun 9, 2015 at 9:56 PM, Jessica Hamilton < jessica.l.hamilton@gmail.com> wrote:

...

...

On Fri, Jun 5, 2015 at 9:42 PM, Edward Diener wrote:

> I think I know what is wrong in the predef-check functionality. > In my VMD > jamfile the use of predef-check, for any given compile or run rule, looks > like: > > [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : > <cxxflags>-std=c++0x ] >

Yes..

What I am seeing is that except on QNX, where "BOOST_OS_QNX != 0", the > '-std=c++0x' is always being added as a C++ compiler flag to the command > line. > > This initially suggests to me that you are treating more than one quoted > predef definition as an OR gate rather than an AND gate. But note > that on > QNX, where where "BOOST_OS_QNX != 0" and "BOOST_COMP_GNUC >= 4.3" is

On 9 June 2015 at 19:40, Rene Rivera wrote: true,

...

> the '-std=c++0x' is not being added. So your logic seems to be > that as you > go through multiple predef definitions once you hit a 'true' > condition you > choose the 'true' path as long as no 'false' conditions follow it, else you > choose the 'false' path. > > Please see if you can fix this given this clue about how > predef-check is > working for the VMD regression tests on various platforms/compilers.

I don't know if it helped but I did a change to one of the tests I do to completely cover all the Venn variations of the binary and expression. I changed my test to this:

[ run check_value.cpp : : : <test-info>always_show_run_output [ predef-check "BOOST_COMP_CLANG > 0" "BOOST_OS_LINUX == 0" : : <cxxflags>-DCHECK_VALUE=true : <cxxflags>-DCHECK_VALUE=false ] ]

Out of curiosity, what happens if you remove the second <cxxflags> variable, and use an #ifndef check, and run again? It's the only difference I can notice between the two examples.

OK.. Did that change. My local OSX test shows "CHECK_VALUE == 1" as expected and correctly. In a few minutes I'll post what the online tests show. But the expectation is that they should all show "CHECK_VALUE == undefined".

And the online tests are now done. And indeed they all print out "CHECK_VALUE == undefined".

Feel free to take a look at my VMD tests jamfile. If you see anything you think is wrong I can change it. I don't think it is the jamfile but something having to do with the Android and SunOS operating systems. I realize that I was wrong in thinking that -std=c++0x is always added, annd that this was my mistake. The tests for SunOS do not look right. http://www.boost.org/development/tests/develop/developer/output/oracle-intel...

1) -Wno-variadic-macros is not a valid option on SunOS. 2) -std=c++0x and -compat=5 are incompatible 3) -std and -library=stlport4 are incompatible

Its a predef problem. See the other post I just responded to on this thread.

On Tue, Jun 16, 2015 at 7:03 PM, Edward Diener wrote:

On 6/10/2015 12:36 AM, Rene Rivera wrote:

...

On Tue, Jun 9, 2015 at 10:34 PM, Rene Rivera wrote:

On Tue, Jun 9, 2015 at 9:56 PM, Jessica Hamilton <

...

jessica.l.hamilton@gmail.com> wrote:

On 9 June 2015 at 19:40, Rene Rivera wrote:

...

...

On Fri, Jun 5, 2015 at 9:42 PM, Edward Diener

...

wrote:

I think I know what is wrong in the predef-check functionality. In my

...

VMD

...

jamfile the use of predef-check, for any given compile or run rule,

...

looks

...

like:

...

[ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ]

Yes..

What I am seeing is that except on QNX, where "BOOST_OS_QNX != 0", the

...

'-std=c++0x' is always being added as a C++ compiler flag to the

command

...

line.

...

This initially suggests to me that you are treating more than one

quoted

...

predef definition as an OR gate rather than an AND gate. But note that

...

on

...

QNX, where where "BOOST_OS_QNX != 0" and "BOOST_COMP_GNUC >= 4.3" is

...

true,

...

the '-std=c++0x' is not being added. So your logic seems to be that as

...

you

...

go through multiple predef definitions once you hit a 'true' condition

...

you

...

choose the 'true' path as long as no 'false' conditions follow it,

...

else you

...

choose the 'false' path.

...

Please see if you can fix this given this clue about how predef-check

is

...

working for the VMD regression tests on various platforms/compilers.

...

I don't know if it helped but I did a change to one of the tests I do to completely cover all the Venn variations of the binary and expression. I changed my test to this:

[ run check_value.cpp : : : <test-info>always_show_run_output [ predef-check "BOOST_COMP_CLANG > 0" "BOOST_OS_LINUX == 0" : : <cxxflags>-DCHECK_VALUE=true : <cxxflags>-DCHECK_VALUE=false ] ]

Out of curiosity, what happens if you remove the second <cxxflags> variable, and use an #ifndef check, and run again? It's the only difference I can notice between the two examples.

OK.. Did that change. My local OSX test shows "CHECK_VALUE == 1" as expected and correctly. In a few minutes I'll post what the online tests show. But the expectation is that they should all show "CHECK_VALUE == undefined".

And the online tests are now done. And indeed they all print out "CHECK_VALUE == undefined".

Please look at the latest 'develop' results for SunOS. The value of BOOST_COMP_CLANG = 0 and yet your check_value test shows CHECK_VALUE == 1. Also the msvc-14.0 tests under Windows shows the same problem.

I'm looking :-) Such a painful problem to track down :-( -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 6/17/2015 10:29 AM, Rene Rivera wrote:

On Tue, Jun 16, 2015 at 8:56 PM, Rene Rivera wrote:

...

On Tue, Jun 16, 2015 at 7:03 PM, Edward Diener wrote:

...

Please look at the latest 'develop' results for SunOS. The value of BOOST_COMP_CLANG = 0 and yet your check_value test shows CHECK_VALUE == 1. Also the msvc-14.0 tests under Windows shows the same problem.

I'm looking :-) Such a painful problem to track down :-(

FYI.. It's something wrong with the check C program itself, not the BB layer on top of it. And I can see msvc-14.0, sun-stlport, gcc- 4.9.2~c14, and gcc- 5.1~c14 showing the problem :-(

You can look at the VMD tests to see when it is not working there. The failures due to predef-check not w0rking properly are occurring on Android with gcc 4.8 and 4.9, SunOS with Oracle C++, Linux with IBM C++ compiler, and Windows with VC++14.

On Sat, Jun 20, 2015 at 7:54 AM, Edward Diener wrote:

On 6/17/2015 10:29 AM, Rene Rivera wrote:

...

On Tue, Jun 16, 2015 at 8:56 PM, Rene Rivera wrote:

...

On Tue, Jun 16, 2015 at 7:03 PM, Edward Diener wrote:

...

Please look at the latest 'develop' results for SunOS. The value of BOOST_COMP_CLANG = 0 and yet your check_value test shows CHECK_VALUE == 1. Also the msvc-14.0 tests under Windows shows the same problem.

I'm looking :-) Such a painful problem to track down :-(

FYI.. It's something wrong with the check C program itself, not the BB layer on top of it. And I can see msvc-14.0, sun-stlport, gcc- 4.9.2~c14, and gcc- 5.1~c14 showing the problem :-(

Could this have something to do with "cached" values ?

No. As I don't think any testers run incremental tests.

Anyway I thought this might give a little more of a clue in solving the predef-check problem since it has occurred locally in my testing.

I don't know if it did.. But I've now rewritten the check (and info) code (a handful of times in the past few weeks) and it should resolve the low level check problems (see < https://github.com/boostorg/predef/commit/0f113b0871832aafdffed45a5def8f4731...

).

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 6/29/2015 10:36 PM, Rene Rivera wrote:

On Sat, Jun 20, 2015 at 7:54 AM, Edward Diener wrote:

...

On 6/17/2015 10:29 AM, Rene Rivera wrote:

...

On Tue, Jun 16, 2015 at 8:56 PM, Rene Rivera wrote:

...

On Tue, Jun 16, 2015 at 7:03 PM, Edward Diener wrote:

...

Please look at the latest 'develop' results for SunOS. The value of BOOST_COMP_CLANG = 0 and yet your check_value test shows CHECK_VALUE == 1. Also the msvc-14.0 tests under Windows shows the same problem.

I'm looking :-) Such a painful problem to track down :-(

FYI.. It's something wrong with the check C program itself, not the BB layer on top of it. And I can see msvc-14.0, sun-stlport, gcc- 4.9.2~c14, and gcc- 5.1~c14 showing the problem :-(

Could this have something to do with "cached" values ?

No. As I don't think any testers run incremental tests.

...

Anyway I thought this might give a little more of a clue in solving the predef-check problem since it has occurred locally in my testing.

I don't know if it did.. But I've now rewritten the check (and info) code (a handful of times in the past few weeks) and it should resolve the low level check problems (see < https://github.com/boostorg/predef/commit/0f113b0871832aafdffed45a5def8f4731...

...

).

Closer but not quite there. The predef-check is now working with Windows msvc-14.0 and with the SunOS tests but there is still a problem with Android. The problem occurs in the VMD tests but can be illustrated by predef tests also. Look at the "CrystaX.NET-apilevel-21-x86" predef tests, which have your latest June 29 commit you mention just above. If you look at the "clang-linux-3.6" tests you will see that the "info_as_cpp" test shows everything correctly but the "check_value" test shows "CHECK_VALUE == undefined" where it should be "CHECK_VALUE == 1". Similarly my corresponding VMD Android tests, which relies on predef-check to pass "-std=c++0x" for the gcc tests, are not doing so there. So there is still a problem with Android although Sun-OS and VC++14 tests are working fine now with predef-check. As always I appreciate your efforts to get this working, especially on OSs like SunOS and Android rather than the usual Windows, Linux, Macintosh triplet.

PS.. On Fri, Jul 3, 2015 at 10:55 AM, Rene Rivera wrote:

And the really bad news.. Is that this is something that is not immediately fixable. Further it's something that is really hard to fix as it would involve creating a whole bunch of code for running those tests on the target-os remotely.

Although I just thought about something.. It might be possible to do compile checks in addition to, or instead of, the run style test. Which would be easier to deal with. I'll see if I can make that work.. But I can't promise anything near term as I'm traveling for a month so will have even more limited free time than usual. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 7/3/2015 11:55 AM, Rene Rivera wrote:

After some investigation...

On Thu, Jul 2, 2015 at 11:07 PM, Edward Diener wrote:

...

Closer but not quite there.

The predef-check is now working with Windows msvc-14.0 and with the SunOS tests but there is still a problem with Android.

Technically it's working on all ;-)

...

The problem occurs in the VMD tests but can be illustrated by predef tests also. Look at the "CrystaX.NET-apilevel-21-x86" predef tests, which have your latest June 29 commit you mention just above. If you look at the "clang-linux-3.6" tests you will see that the "info_as_cpp" test shows everything correctly but the "check_value" test shows "CHECK_VALUE == undefined" where it should be "CHECK_VALUE == 1".

Similarly my corresponding VMD Android tests, which relies on predef-check to pass "-std=c++0x" for the gcc tests, are not doing so there.

So there is still a problem with Android although Sun-OS and VC++14 tests are working fine now with predef-check.

Some good news and bad news.. I know what the last problem is now. It's because Android is a cross-compiler, it build on Linux but targets Android in this case. The good news is that the BB check builds and runs fine, on the host-os Linux build machine. The bad news is that the result of running that on the host-os machine is useless for making a determination of the target-os build for the libraries.

And the really bad news.. Is that this is something that is not immediately fixable. Further it's something that is really hard to fix as it would involve creating a whole bunch of code for running those tests on the target-os remotely.

Hence, my suggestion would be to change your build file to also check the "target-os" build property. You might want to bring this up, how to check the target-os in your use case, on another thread and perhaps on the Boost Build list (so that it gets more immediate attention).

My test in the VMD jamfile is: [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] but despite Android telling me that it is using gcc 4.8 and gcc 4.9 the "-std=c++0x" option never gets added to the command line. This has nothing to do with the build OS/target OS issue you are mentioning. Your predef test for the same Android tests shows BOOST_COMP_GNUC = 40800000 (4,8,0) | Gnu GCC C/C++ BOOST_OS_QNX = 0 | QNX and BOOST_COMP_GNUC = 40900000 (4,9,0) | Gnu GCC C/C++ BOOST_OS_QNX = 0 | QNX What is further odd is that I also have these predef-check setups in the jamfile: [ predef-check "BOOST_COMP_GNUC >= 4.8.1" : : <cxxflags>-ftrack-macro-expansion=0 ] [ predef-check "BOOST_COMP_GNUC >= 4.3.0" : : <cxxflags>-Wno-variadic-macros ] Yet neither of those options are showing up on the command line for the tests. It seems to me that for the Android maybe the cause is that despite compiling with g++ the compile is being treated as a C compile and not a C++ compile so that cxxflags does not take effect. On all other tests with gcc all the appropriate options are working fine.

...

As always I appreciate your efforts to get this working, especially on OSs like SunOS and Android rather than the usual Windows, Linux, Macintosh triplet.

Thanks.. I appreciate the gratitude. As it's some times hard to tell if people actually care :-)

On 6/9/2015 10:56 PM, Jessica Hamilton wrote:

On 9 June 2015 at 19:40, Rene Rivera wrote:

...

On Fri, Jun 5, 2015 at 9:42 PM, Edward Diener wrote:

...

I think I know what is wrong in the predef-check functionality. In my VMD jamfile the use of predef-check, for any given compile or run rule, looks like:

[ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ]

Yes..

What I am seeing is that except on QNX, where "BOOST_OS_QNX != 0", the

...

'-std=c++0x' is always being added as a C++ compiler flag to the command line.

This initially suggests to me that you are treating more than one quoted predef definition as an OR gate rather than an AND gate. But note that on QNX, where where "BOOST_OS_QNX != 0" and "BOOST_COMP_GNUC >= 4.3" is true, the '-std=c++0x' is not being added. So your logic seems to be that as you go through multiple predef definitions once you hit a 'true' condition you choose the 'true' path as long as no 'false' conditions follow it, else you choose the 'false' path.

Please see if you can fix this given this clue about how predef-check is working for the VMD regression tests on various platforms/compilers.

I don't know if it helped but I did a change to one of the tests I do to completely cover all the Venn variations of the binary and expression. I changed my test to this:

[ run check_value.cpp : : : <test-info>always_show_run_output [ predef-check "BOOST_COMP_CLANG > 0" "BOOST_OS_LINUX == 0" : : <cxxflags>-DCHECK_VALUE=true : <cxxflags>-DCHECK_VALUE=false ] ]

Out of curiosity, what happens if you remove the second <cxxflags> variable, and use an #ifndef check, and run again? It's the only difference I can notice between the two examples.

What happens if you specify: [ run check_value.cpp : : : <test-info>always_show_run_output [ predef-check "BOOST_COMP_CLANG > 0" "BOOST_OS_LINUX == 0" : : <cxxflags>-DCHECK_VALUE=true ] ] In my tests I am leaving off the predef-check last colon ( ':' ) completely. Could that be the cause of the problem ? I will update my jam file by inserting it back in and see if that fixes things.

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 wrote:

...

On Mon, May 18, 2015 at 8:57 PM, Edward Diener wrote:

...

On 5/15/2015 4:38 PM, Rene Rivera wrote:

...

On Fri, May 15, 2015 at 3:31 PM, Edward Diener 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-SP..., 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..., 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).

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 wrote:

...

On Mon, May 18, 2015 at 8:57 PM, Edward Diener wrote:

> On 5/15/2015 4:38 PM, Rene Rivera wrote: > >> On Fri, May 15, 2015 at 3:31 PM, Edward Diener >> >> 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-SP...,

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

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.