Rene Rivera <grafik.list@redshift-software.com> 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 http://www.boost-consulting.com