[Bf-committers] scons and static libs

[Ken Hughes]

Stephen Swaney wrote:
> On Wed, Apr 16, 2008 at 09:54:38PM -0700, Ken Hughes wrote:
>   
>> I don't know if the other platform managers have this issue, but it's a 
>> bit of a pain to make the releases using the minimum number of shared 
>> libraries.  My solution has been to create a separate directory 
>> containing the static libs I want to use and then override the default 
>> scons variables  for them.  For example, I link OpenAL, OpenEXR, and PNG 
>> statically.  I can't use the "out-of-the-box" static libs since gcc 
>> needs to separate the shared and static libs with a "-Xlinker -Bstatic".
>>
>> I'd like to propose one of two solutions:
>>
>> (1) Specify the libs using a shared (".so") or static (".a") suffix.  
>> Parse each BF_*_LIB string and tack the lib into either a shared or 
>> static list, then send these to the linker separated by the appropriate 
>> platform-specific flags ("-Xlinker -Bstatic" for linux, for example).  I 
>> played with the output of scons and found that this worked reliably, 
>> including the shared or static OpenGL libs.
>>
>> (2) The static OpenGL libs are handled by passing the explicit static 
>> libs to gcc.  This can't be done as far as I can tell using something 
>> like BF_FREETYPE_LIB='/usr/lib/libfreetype.a' because scons expands 
>> BF_*_LIB to a string of libs with "-l" tacked on the front of each.  I 
>> played around with tools/Blender.py and found it wasn't too hard to 
>> check for something like "/usr" or ".a" in the BF_*_LIB strings and if 
>> true tack those libs onto the static library list.
>>     
>
> Of the two solutions, #1 sounds the least hacky (at least before the
> coffee kicks in!).
>
> Thinking out loud, maybe we need a separate BF_STATIC_LIBS to hold our
> statically linked items.
>
>   
I'm obviously open to either (any) good approach; for #1 I'm just unsure 
of how this would be handled in a non-gcc world (msvc, sun, irix, etc).

Ken