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

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.