Boost logo

Boost :

Subject: Re: [boost] [predef] Using predef-check on 'develop' problem
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-20 08:54:15


On 6/17/2015 10:29 AM, Rene Rivera wrote:
> On Tue, Jun 16, 2015 at 8:56 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
>>
>> On Tue, Jun 16, 2015 at 7:03 PM, Edward Diener <eldiener_at_[hidden]>
>> 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 ? I started to see
errors when running VMD tests with gcc locally as to the predef values
shown just after the "Performing configuration checks" line of the
output. Even though I was testing gcc-4.7.2 predef-check was showing
that "- BOOST_COMP_GNUC >= 4.3.0 : no (cached)". Later on, perhaps after
running a b2 --clean for VMD and gcc=4.7.2, the check for gcc somehow
straightened itself out and I was correctly seeing "- BOOST_COMP_GNUC >=
4.3.0 : yes". I do not know what "(cached)" is supposed to mean but is
it possible that some predef-check for another earlier invocation of gcc
was being picked up somehow ( I was actually testing gcc-3.3.3 earlier )
? 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk