
When I build and run config_info using msvc-stlport I get the output below which doesn't seem correct. I get no reference to stlport. When I investigate the bjam output I find (for another test) I find that the following is being used for the command line: "cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\BoostMainCVS" -I"c:/Program Files/microsoft visual studio\vc98\include" -I"c:\STLport-4.5.3\stlport" -Fo"..\..\..\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlpo rt\debug\threading-multi\no_ded_typename_fail.obj" -Tp"..\..\..\libs\config\test\no_ded_typename_fail.cpp" This indicates that the Microsoft native include is specified BEFORE the STLPort one. This would explain why the config_info doesn't reflect the STLPort usage. Can someone tell me what I should be doing differently? Robert Ramey Microsoft Visual C++ version 6.0 _CPPUNWIND =1 __cplusplus =1 _M_IX86 =500 _WIN32 =1 _WCHAR_T_DEFINED [no value] _CPPRTTI =1 _DLL =1 _MSC_EXTENSIONS =1 _MSC_VER =1200 _MT =1 __BOOL_DEFINED =1 ********************************************************************* Dinkumware standard library version 1.x ********************************************************************* Detected Platform: Win32 Type char is signed Type wchar_t is unsigned byte order for type short =0 8 byte order for type int =0 8 16 24 byte order for type long =0 8 16 24 sizeof(wchar_t) =2 sizeof(short) =2 sizeof(int) =4 sizeof(long) =4 sizeof(size_t) =4 sizeof(ptrdiff_t) =4 sizeof(void*) =4 sizeof(void(*)(void)) =4 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =8 CHAR_BIT =8 CHAR_MAX =127 WCHAR_MAX =((wchar_t)-1) SHRT_MAX =32767 INT_MAX =2147483647 LONG_MAX =2147483647L ********************************************************************* Boost version 103100 BOOST_USER_CONFIG =<boost/config/user.hpp> BOOST_COMPILER_CONFIG ="boost/config/compiler/visualc.hpp" BOOST_STDLIB_CONFIG ="boost/config/stdlib/dinkumware.hpp" BOOST_PLATFORM_CONFIG ="boost/config/platform/win32.hpp" BOOST_BCB_PARTIAL_SPECIALIZATION_BUG [no value] BOOST_DEDUCED_TYPENAME [no value] BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL [no value] BOOST_HAS_DECLSPEC [no value] BOOST_HAS_FTIME [no value] BOOST_HAS_MACRO_USE_FACET [no value] BOOST_HAS_MS_INT64 [no value] BOOST_HAS_THREADS [no value] BOOST_HAS_WINTHREADS [no value] BOOST_MSVC =1200 BOOST_MSVC_STD_ITERATOR =1 BOOST_MSVC6_MEMBER_TEMPLATES [no value] BOOST_NESTED_TEMPLATE =template BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP [no value] BOOST_NO_ARRAY_TYPE_SPECIALIZATIONS [no value] BOOST_NO_CV_VOID_SPECIALIZATIONS [no value] BOOST_NO_DEDUCED_TYPENAME [no value] BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS [no value] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS [no value] BOOST_NO_FUNCTION_TEMPLATE_ORDERING [no value] BOOST_NO_HASH [no value] BOOST_NO_INCLASS_MEMBER_INITIALIZATION [no value] BOOST_NO_INTEGRAL_INT64_T [no value] BOOST_NO_INTRINSIC_WCHAR_T [no value] BOOST_NO_LONG_LONG_NUMERIC_LIMITS [no value] BOOST_NO_MEMBER_TEMPLATE_FRIENDS [no value] BOOST_NO_MEMBER_TEMPLATES [no value] BOOST_NO_MS_INT64_NUMERIC_LIMITS [no value] BOOST_NO_PRIVATE_IN_AGGREGATE [no value] BOOST_NO_SFINAE [no value] BOOST_NO_SLIST [no value] BOOST_NO_STD_ALLOCATOR [no value] BOOST_NO_STD_ITERATOR [no value] BOOST_NO_STD_ITERATOR_TRAITS [no value] BOOST_NO_STD_MIN_MAX [no value] BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN [no value] BOOST_NO_STD_USE_FACET [no value] BOOST_NO_STDC_NAMESPACE [no value] BOOST_NO_SWPRINTF [no value] BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION [no value] BOOST_NO_TEMPLATE_TEMPLATES [no value] BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS [no value] BOOST_NO_USING_TEMPLATE [no value] BOOST_NO_VOID_RETURNS [no value] BOOST_STD_EXTENSION_NAMESPACE =std BOOST_UNREACHABLE_RETURN(0) [no value] EXIT STATUS: 0

"Robert Ramey" <ramey@rrsd.com> writes:
When I build and run config_info using msvc-stlport I get the output below which doesn't seem correct. I get no reference to stlport.
When I investigate the bjam output I find (for another test) I find that the following is being used for the command line:
"cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\BoostMainCVS" -I"c:/Program Files/microsoft visual studio\vc98\include" -I"c:\STLport-4.5.3\stlport" -Fo"..\..\..\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlpo rt\debug\threading-multi\no_ded_typename_fail.obj" -Tp"..\..\..\libs\config\test\no_ded_typename_fail.cpp"
This indicates that the Microsoft native include is specified BEFORE the STLPort one. This would explain why the config_info doesn't reflect the STLPort usage.
Can someone tell me what I should be doing differently?
Looks to me like someone broke the toolset. I suggest you track them down in its CVS history and get them to fix it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

When I build and run config_info using msvc-stlport I get the output below which doesn't seem correct. I get no reference to stlport.
When I investigate the bjam output I find (for another test) I find that the following is being used for the command line:
"cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\BoostMainCVS" -I"c:/Program Files/microsoft visual studio\vc98\include" -I"c:\STLport-4.5.3\stlport" -Fo"..\..\..\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlpo rt\debug\threading-multi\no_ded_typename_fail.obj" -Tp"..\..\..\libs\config\test\no_ded_typename_fail.cpp"
This indicates that the Microsoft native include is specified BEFORE the STLPort one. This would explain why the config_info doesn't reflect the STLPort usage.
Can someone tell me what I should be doing differently?
I don't know, but the dmc toolset is broken for the same reason. Actually this seems to me to be a bad design decision: why would the compilers include directory be present on the command line at all? If my compilers environment has been modified to place some other directory first (for example in vcvars32.bat) then why would bjam subvert that? John.

Robert Ramey wrote:
When I build and run config_info using msvc-stlport I get the output below which doesn't seem correct. I get no reference to stlport.
When I investigate the bjam output I find (for another test) I find that the following is being used for the command line:
"cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\BoostMainCVS" -I"c:/Program Files/microsoft visual studio\vc98\include" -I"c:\STLport-4.5.3\stlport" -Fo"..\..\..\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlpo rt\debug\threading-multi\no_ded_typename_fail.obj" -Tp"..\..\..\libs\config\test\no_ded_typename_fail.cpp"
This indicates that the Microsoft native include is specified BEFORE the STLPort one. This would explain why the config_info doesn't reflect the STLPort usage.
That it would.
Can someone tell me what I should be doing differently?
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: vc-C++ C:\Boost\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlport\debug\threading-multi\no_ded_typename_fail.obj CALL "C:\Program Files\Microsoft Visual Studio\VC98\bin\VCVARS32.BAT" >nul "C:\Program Files\Microsoft Visual Studio\VC98\bin\cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\CVSROOTs\Boost\boost" -I"C:\Boost\STLport-4.6.2\stlport" -Fo"C:\Boost\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlport\debug\threading-multi\no_ded_typename_fail.obj" -Tp"..\..\..\libs\config\test\no_ded_typename_fail.cpp" Which as you can see doesn't include the VC include path. That indicates that there is something different about your setup. Are you using a custom toolset, or the msvc-stlport-tools.jam directly? If you have a custom toolset what does that look like? And for reference I used the stock msvc-stlport-tools.jam. And I invoked BBv1 as such: bjam -sALL_LOCATE_TARGET=C:\Boost -n -d+2 -sPYTHON_ROOT=C:\Python22 -sTOOLS=msvc-stlport -sSTLPORT_PATH=C:\Boost -sSTLPORT_VERSION=4.6.2 -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

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 ...patience... ...found 378 targets... ...updating 9 targets... MkDir1 ..\..\..\bin\boost\libs\config\test\config_test.test mkdir "..\..\..\bin\boost\libs\config\test\config_test.test" MkDir1 ..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport mkdir "..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport" MkDir1 ..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport\debug mkdir "..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport\d ebug" MkDir1 ..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport\debug\ threading-multi mkdir "..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport\d ebug\threading-multi" vc-C++ ..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport\debug\ threading-multi\config_test.obj "cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /Zc:forScope -I".. \..\..\bin\boost\libs\config\test" -I"C:\data\boost\develop\boost" -I"C:\Progra m Files\Microsoft Visual Studio .NET 2003\VC7\include" -I"c:\download\open\stlpo rt\STLport-4.6.2\stlport" -Fo"..\..\..\bin\boost\libs\config\test\config_test. test\vc7.1-stlport\debug\threading-multi\config_test.obj" -Tp"..\..\..\libs\con fig\test\config_test.cpp" config_test.cpp command-file-dump ..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stl port\debug\threading-multi\config_test.CMD IF EXIST "..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport \debug\threading-multi\config_test.CMD" DEL "..\..\..\bin\boost\libs\config\test \config_test.test\vc7.1-stlport\debug\threading-multi\config_test.CMD" echo "..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport\deb ug\threading-multi\config_test.obj">>..\..\..\bin\boost\libs\config\test\config_ test.test\vc7.1-stlport\debug\threading-multi\config_test.CMD vc-Link ..\..\..\bin\boost\libs\config\test\config_test.test\vc7.1-stlport\debug \threading-multi\config_test.exe Note the extra "bad" include, I see the same behaviour with the msvc-stlport, vc7-stlport and vc7.1-stlport toolsets. John.

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. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

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? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

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

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.
Excellent, many thanks, that seems to be working fine for me now.
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?
Hallucinating :-) No seriously I would expect user-includes to come first. John.
participants (4)
-
David Abrahams
-
John Maddock
-
Rene Rivera
-
Robert Ramey