Re: Boost 1.25.0 build problems?

From: williamkempf_at_[hidden]
Date: 2001-10-04 11:22:38

--- In boost_at_y..., "Markus Schoepflin" <markus.schoepflin_at_g...> wrote:
> --- In boost_at_y..., williamkempf_at_h... wrote:
> > This shouldn't be happening (and doesn't for me). Be sure to run 
> Jam 
> > with -f??\boost\tools\build\allyourbase.jam.
> >  
> 
> This happens when I try it:
> 
> C:\src\boost_1_25_0>jam -ftools\build\allyourbase.jam -
sTOOLS="msvc" -
> sBUILD="<include>%STL_INCLUDE%" -a
> ...found 669 targets...
> ...updating 12 targets...
> msvc-C++-action 
> libs\thread\build\bin\libboost_thread\msvc\debug\runtime-link-
> dynamic\threading-multi\condition.obj
> condition.cpp
> libs\thread\build\../src\condition.cpp(12) : fatal error C1083: 
> Cannot open include file: 'boost/thread/condition.hpp':
> No such file or directory
>
>     C:\PROGRA~1\MICROS~1\VC98\bin\cl  /Zm400 -nologo -GX -
> c   /Zi /Od /Ob0 /GX /GR /MDd   -I"libs\thread\build" -I"libs\
> thread\build\." -I"\\Kiew\Entwicklung\Plattformen\STL\STLport-4.0
> \stlport"  -I"C:\PROGRA~1\MICROS~1\VC98\include"  -Fo"l
> ibs\thread\build\bin\libboost_thread\msvc\debug\runtime-link-
> dynamic\threading-multi\condition.obj"  -Tp"libs\thread\bui
> ld\../src\condition.cpp"
> 
> It works if I replace BOOST_ROOT with ../../.. or if I do set 
> BOOST_ROOT manually.

I can't claim to understand why this is happening.  I do not receive 
this problem at all.  Which Jam executable are you using?  We may 
need Dave Abrahams to chime in on this one.  I can only guess that 
there's some environment problem, but I can see what.

> > > But I had to add the header <string> to "exceptions.hpp", 
> otherwise 
> > > the compilation of the constructors of the exceptions objects 
> > failed. 
> > > But this may be an issue with STLPort 4.0.
> > 
> > I don't use STLPort, though I thought Beman ran Win32 compiles 
with 
> > this?  I'll look into this one.
> > 
> 
> This is the error I get without including <string> 
> in "exceptions.hpp":
> 
> msvc-C++-action 
> libs\thread\build\bin\libboost_thread\msvc\debug\runtime-link-
> dynamic\threading-multi\condition.obj
> condition.cpp
> libs\thread\build\..\..\..\boost/thread/exceptions.hpp(36) : error 
> C2664: '__thiscall _STLD::runtime_error::_STLD::runti
> me_error(const class _STLD::basic_string<char,struct 
> std::char_traits<char>,class _STLD::allocator<char> > &)' : cannot
> convert parameter 1 from 'char [18]' to 'const class 
> _STLD::basic_string<char,struct std::char_traits<char>,class _STLD:
> :allocator<char> > &'
>         Reason: cannot convert from 'char [18]' to 'const class 
> _STLD::basic_string<char,struct std::char_traits<char>,c
> lass _STLD::allocator<char> >'
>         Source or target has incomplete type
> libs\thread\build\..\..\..\boost/type_traits/ice.hpp(80) : fatal 
> error C1506: unrecoverable block scoping error
> 
> Looks like basic_string is only fwd declared at his point.

I'm not sure if STLPort is compliant here or not, but this causes 
grief.  The standard explicitly says that the std::exception types 
should all take an argument of type "const string&" in their 
constructors.  The fact that the type is a reference may allow 
implementations to only forward declare std::string here, but doing 
so is a questionable practice as it doesn't accomplish much of 
anything.  Any code that constructs a std::exception type is going to 
have to include <string> any way, so very few compilation units will 
benefit from the "optimization".  It won't hurt for me to include 
<string> in <boost/thread/exceptions>, but I really question why I 
should have to.

Bill Kempf