[Boost-build] [v2] [stlport.jam] A few issues

From: David Deakins (ddeakins_at_[hidden])
Date: 2006-09-27 16:41:10

I was testing BBv2 from RC_1_34_0 on some of my builds that use STLport 
and I ran across a few small issues.  These tests were all on a WinXP 
machine and I was using STLport 5.1 RC2 with VC8 and VC8 cross-compiling 
for Windows CE 5.0/x86.  If these issues have already been mentioned 
previously, please forgive my duplication:

1) In line 223 of stlport.jam, runtime-debugging=on is checked to decide 
whether <define>_STLP_USE_DYNAMIC_LIB=1 should be added to the usage 
requirements.  Based on what that flag means and also on the comments in 
the header of stlport.jam, it seemed like link=shared should be checked 
here (rather than runtime-debugging=on).

2) When building libraries with STLport 5.1 and using link=shared and 
runtime-link=shared, the link.dll action was failing with

   LINK : fatal error LNK1181: cannot open input file 'stlportstld.5.lib'

The STLport 5.x libraries use names like stlportxxx.5.x.lib.  The 
stlport.jam file correctly reflects this v5 naming convention (lines 
130-143), but the .1 in stlportstld.5.1 was getting dropped before the 
library name shows up the link RSP file.  After some investigation, it 
appears that this is occurring in msvc.jam in line 738 where libraries 
are added to the link RSP file with the expression:

   $(FINDLIBS_ST:S=.lib)

The :S= modifier is treating the .1 in stlportstd.5.1 as a suffix and 
dutifully removing it.  It seems like this can be fixed by either 
removing the :S= modifier in msvc.jam or adding a .lib in stlport.jam. 
I wasn't clear to me which method is preferred.

3) Since I compile different builds of the STLport libraries for 
vc8-win32 and vc8-winCE-x86, my user-config.jam up is set up like so:

  using stlport : 5.1~vc8 : C:/STLPort/STLPort-5.1RC2/stlport
                            C:/STLPort/STLPort-5.1RC2/lib/vc8 ;
  using stlport : 5.1~evc8~x86 : C:/STLPort/STLPort-5.1RC2/stlport
                                 C:/STLPort/STLPort-5.1RC2/lib/evc8-x86 ;

When I specify a specific version of stlport in my build request such as:

bjam --v2 --prefix=C:\Boost --with-signals debug
msvc/threading=multi/link=shared/runtime-link=shared/stdlib=stlport-5.1~vc8 
install

then I get a build path that looks like this:

C:\CVS\Boost_1_34_0\boost\bin.v2\libs\signals\build\msvc-8.0\debug
\stdlib-stlport-5.1~vc8\stdlib-stlport-5.1~vc8\threading-multi

(Note that 'stdlib-stlport-5.1~vc8' is repeated twice.)

This is a small issue, but I spent a little bit of time looking into it. 
  Apparently the duplication comes from line 260 in stlport.jam where 
<stdlib>stlport-$(self.version) is added to the usage requirements when 
a specific STLport version is requested (as opposed to just 
<stdlib>stlport getting added when only a single version of STLport is 
available).  At the time when Boost.Build merges the STLport usage 
requirements with the properties in the original build request, the 
<stdlib>stlport-5.1~vc8 property from the build request has been split 
into <stdlib>stlport and <stdlib-stlport:version>5.1~vc8 properties.  As 
a result, the usage requirement for <stdlib>stlport-5.1~vc8 specified on 
line 260 of stlport.jam does not seem to get filtered out as a 
duplicate.  So then later on when <stdlib>stlport and 
<stdlib-stlport:version> are back as a single propery and the build path 
is created, <stdlib>stlport-5.1~vc8 ends up being in the property set 
twice and causes the duplication in the directory structure.  In my 
tests, if line 259-260 of stlport.jam are changed to:

  usage-requirements +=
     <stdlib>stlport <stdlib-stlport:version>$(self.version) ;

then the duplication is eliminated.  However, I'm certainly not a 
Boost.Build expert and I may be missing something or there may be a 
better solution.

Thanks for your help,
-Dave