Re: [boost] Re: stlport config patch and ???-stlport.jam tools

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-07-20 21:49:47

[2002-07-20] Gennadiy Rozental wrote:
>2. In general current situation with stlport based toolsets seems
>unaceptable. Why do we need to repeat this work for every toolset: msvc,
>gcc, sunpro .... There exist some differencies but they are minimal. I am
>attaching of sunpro-stlport toolset definition that has stlport
>configurations factored out. I am gonna prepare docs for it and present for
>inclusion into tools/build. But I think that it worth considering that all
>stlport based tools use the same confoguration

Yes there is plenty of duplication when it comes to handling STLport support
in the current Boost.Build-V1. This situation is actually a holdover from
before I got involved in the build system. There are better ways to do this
support now, but we always thought that V2 would be in use before this
really became an issue, at which point the hopefully optimum solution would
be used. Even I don't use the support for STLport currently in the build
system even though I do use STLport with GCC. Instead I use the more modern
way to add orthogonal configuration like this:

STLPORT_ROOT
    = $(SDKROOT)/STLport ;
##
##  STLport...
##
if $(NT) {
    STLPORT_LIB_ID = cygwin ; }
else {
    STLPORT_LIB_ID = gcc ; }
STLPORT_LIB_DIRECTORY = $(STLPORT_ROOT)/lib-$(STLPORT_LIB_ID)-$(GCC_VERSION)
;
STLPORT_LIB_NAME = stlport_$(STLPORT_LIB_ID) ;
STLPORT_LIB_NAME_DEBUG = stlport_$(STLPORT_LIB_ID)_stldebug ;
STLPORT_INCLUDE_DIRECTORY = $(STLPORT_ROOT)/stlport ;

variant stlport
    :
        <sysinclude>$(STLPORT_INCLUDE_DIRECTORY)
        <gcc><library-path>$(STLPORT_LIB_DIRECTORY)
    ;
variant stlport-dynamic
    :
        <define>_STLP_USE_DYNAMIC_LIB
    ;
variant stlport-release : stlport
    :
        <find-library>$(STLPORT_LIB_NAME)
    ;
variant stlport-debug : stlport
    :
        <find-library>$(STLPORT_LIB_NAME_DEBUG)
        <gcc><linkflags>"-Wl,-rpath -Wl,$(STLPORT_LIB_DIRECTORY)"
        <define>_STLP_DEBUG=1
    ;
variant stlport-profile : stlport
    :
        <find-library>$(STLPORT_LIB_NAME)
        <gcc><linkflags>"-Wl,-rpath -Wl,$(STLPORT_LIB_DIRECTORY)"
    ;

[and these are the variants I actually use for building...]
variant thot-debug
    :
        stlport-debug
        thot-common debug
    :
        <gcc><linkflags>"-Wl,-rpath -Wl,."
        <gcc><linkflags>"-Wl,-rpath -Wl,$(GCC_STDLIB_DIRECTORY)"
    ;
variant thot-release
    :
        stlport-release
        thot-common release
    :
    ;
variant thot-profile
    :
        stlport-profile
        thot-common profile
    :
        <debug-symbols>on
    ;

Question is... is it time to add such variants to the V1 standard set?

>begin 666 sunpro-stlport-tools.jam
>M(R!T:&ES(&ES('-I;7!L>2!A;B!E>'1E;G-I;VX@=&\@=&AE('-U;G!R;R!T

>begin 666 stlport.jam
>M(R!35$QP;W)T(&EO<W1R96%M<R!O<B!N871I=F4@:6]S=')E86US"F9E871U

I really wish these where in MIME compliant form. That way those of us
reading this with email could extract the attachements :-( Any chance of you
reposting the attachements this way?

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]