François Dumont wrote:
> I will check your modifs, I am surprise that the branch is RC_1_33_0,
> shouldn't it be RC_1_33_1, 1.33.0 is already released no?
It really should be BOOST_1_33, but it's a bit of bad planning when the
release procedures where created.
> For the moment
> the only thing I have notive are:
> - you are using the 'g' suffix for debug version but it is a gcc
> specific suffix, for all other compilers I have plan to use 'd' instead
> (we failed to have a consensus on this point :-( )
Oh, yes I see that now. That's somewhat of a pain as it's not easy to
tell the real toolset in BBv1.
> - you are defining _STLP_THREAD even if building a single threaded
> version of boost.
Yea, I thought I read someplace, in some docs, that there is no
single-threaded support in STLport?
> I know that the single threaded won't link as we have
> modify STLport in order to forbid cross config that is to say a single
> threaded appli using a thread safe STLport lib or, worst, a multi
> threaded appli using a not thread safe STLport lib. I think that for the
> moment we should simply force exclusive build of thread safe boost libs
> when using STLport.
OK, strange that I already do that for the MSVC+STLport combination, but
not for other compilers.
> Later when STLport will have more config options we
> will be able to signal in the doc that users should build the not thread
> safe STLport libs to build the not thread safe boost libs.
> Playing with boost build system I come to some questions:
> - couldn't we create a 'stdlib' feature rather than having all the
> STLport specific toolset. A user could then build STLport using msvc for
> instance like that:
> bjam "-sBUILD=<stdlib>stlport" msvc
> per default the value would be 'native' to signal the compiler native
> std lib. I don't know if the boost build system is able to handle this
> of feature.
Interesting thing is that there already is such a feature :-) It just
never got used :-( But in BBv2 it works more orthogonally, i.e. with the
stdlib feature, so this is not a problem there.
> - isn't use of STLport iostream now the default behavior, according the
> doc it is not...
I was told on the Boost list that STLport iostream is the only available
option now. I.e. that there is no more iostream wrapper mode. So for
STLport-5 the <stlport-iostream> feature is ignored. Is that not correct?
> How do you know a feature default value ? Is it the
> first value in definition of the list of possible values ?
Yes, it's the first value.
> - what about the bjam v2 system ?
I'm only worried about BBv1 for the 1.33.1 release as that's what gets
used out of the box, and since it's the last BBv1 release. I'll work on
BBv2 support a bit later.
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org