From: Markus Schoepflin (markus.schoepflin_at_[hidden])
Date: 2001-11-05 07:04:41
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: "Markus Schöpflin" <markus.schoepflin_at_g...>
>
[snip]
> > - Create a compiler independent STLport jam file which is able to
extend
> any given toolset. I don't know if this is possible, though.
>
> I think it is. However, we should think about the design a bit
first:
>
> 1. Should it be based on a more general mechanism for replacing the
built-in standard library?
Probably yes but I don't know if it's worth the effort.
> 2. Shall we arrange things so that you can build both with and
without
> stlport, and such that each build goes in a separate subvariant
directory?
Yes, and this works already, just say
TOOLS = msvc msvc-stlport ;
et voilà, you end up with both variants.
>
> > - Handling of other STLport versions (betas, bugfix releases)
which don't
> affect link compatibility.
>
> Hmm, I'm not sure there are ever any STLPort revisions that
preserve link
> compatibility.
There will be a 4.5.1 which hopefully preserves link compatibility.
>
> > - Support for different STLport configurations (all these defines
in
> stl_user_config.h) Handle them in the toolset or leave it to the
user?
>
> Good question.
>
> For the most part, stl_user_config is no longer supported, IIRC. I
think the
> only thing worth supporting (and even this is arguable, since it
doesn't
> really work well) is STLP_NO_IOSTREAMS. But maybe I've overlooked
something?
Really? http://www.stlport.com/doc/configure.html doesn't mention
this and the fact that those macros are well documented makes me
belief differently.
Markus