Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-09-01 03:29:35

Rene Rivera <grafik.list_at_[hidden]> writes:

> Rene Rivera wrote:
>> John Maddock wrote:
>>>> Well here's the strange aspect of this; I tested this exact
>>>> configuration before putting those changes in and I get different
>>>> results than you do. Running with latest CVS, and bjam 3.1.10 I
>>>> get for the above compile this:
>>> [snipped]
>>>> Which as you can see doesn't include the VC include path.
>>> That's not what I see, I opened up a Visual studio command prompt and:
>>> C:\data\boost\develop\boost>set BOOST_ROOT=c:\data\boost\develop\boost
>>> C:\data\boost\develop\boost>set TOOLS=vc7.1-stlport
>>> C:\data\boost\develop\boost>set STLPORT_PATH=c:\download\open\stlport
>>> C:\data\boost\develop\boost>cd libs\config\test
>>> C:\data\boost\develop\boost\libs\config\test>bjam -a -d2 config_test
>> Thanks John, I managed to reproduce the problem now. I'll try and
>> fix it tonight.
> OK, it's fixed for all toolsets. But since I can't test all toolsets I
> don't know if my changes will break other things. If they do, it will
> need to be fixed when that comes up. As a warning the big change was
> the mixed use of STD headers and system (<sysinclude>) headers.
> By the way as I changed all the toolsets I noticed that they all set
> up the includes paths in this order:
> 1. user includes
> 2. standard includes
> 3 system includes (this one I just added to fix the above issue)
> But I would have thought that the order should be:
> 1. standard includes
> 2. system includes
> 3. user includes
> Is this a real problem that should be fixed, or am I just hallucinating?

Hard to say. Different compilers have different #include search
protocols. You don't really want user ("") includes overriding
system/standard (<>) includes, but some compilers don't make a
distinction when specifying search paths.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at