|
Boost-Build : |
From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-06-03 10:28:25
[2003-06-03] Vladimir Prus wrote:
>
>I've being thinking/implementing better STLport support, and came to some
>conclusions, that I might need to address now, and which probably must be
>addressed in targets hierarchy redesign. The idea for STLport was simple:
>the <stdlib>stlport is a composite feature, which expands to
><library>@/stlport/stlport.
>
>When the target @/stlport/stlport is generated, necessary
searched-lib-target
>is created, which has appropriate <includes> and <defines> in usage
>requirements.
>
>This all is good, but: when STLPort is used with native iostreams, there's
no
>library to be linked to. However, one still needs proper <includes> and
><defines> for all main target. The only solution I see is in this case the
>@/stlport/stlport main target should generate "special" virtual target. It
>will carry usage requirements, but is not consumed -- i.e. is ignored when
>appearing in sources.
Or write a "modifier" for stlport support that inserts the needed features
taking into account wether it's configured for native streams or not.
So that makes two use cases for modifiers. Perhaps it's time to implement
those now as something other than a generator :-\
-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk