[boost] Re: Thread Lib and DLL

From: Russell Hind (rhind_at_[hidden])
Date: 2003-03-26 11:29:26

William E. Kempf wrote:
> 
> You can do this simply by placing the applications in seperate directories
> and keeping the proper DLL version alongside the executable.  Not
> necessarily the ideal solution, but it's the easiest way to solve "DLL
> Hell".
> 

The reason I've not done this (and want to go to the 'version number in 
name' if we're forced to use dlls) is that I can have all dlls sitting 
in one place on the system, and to create a quick project, I can already 
  use the boost libs without having to copy/move any lib/dll files.  I 
use #pragma link statements (like regex does) in code to link with the 
boost dlls so all I need on my libs path is

C:\BOOST\1.30.0\bin

and change this depending on which version.  The version is also just a 
project wide #define so it can easily be changed on a project by project 
basis (need to change 3 things:

include directory
lib directory
version #define (so the pre-processor can make up the .lib name)

and I can then easily switch between versions and have all versions 
existing on the same machine.  I'm trying to make boost as easy to use 
as the STL, i.e. always available without havig to do anything bar 
include a header file in 1 or more CPP files that contains the #pragma 
link statements.

I've also currently done it by adding a d to the debug version and mt to 
the threaded version (of signals etc) so I can easily switch between the 
debug and release version of a lib if I want to step through the code. 
The multi-threaded version is automatically used if __MT__ is defined etc.

> 
>>Current idea for doing this is re-naming the boost dlls to
>>boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all
>>the dlls in, and each project would link and use the correct dll.  I
>>wonder if support for this could be built into the builds?
> 
> 
> Absolutely!  I'm hoping we address these kind of concerns with a full
> installation solution sometime soon.  In the mean time, the stage rule in
> the Jamfile should be able to handle this.  You can hardcode the release
> number in today... but I believe there's a variable available which I
> could use to do this with out hardcoding.  I'll see if I can track this
> down and make the patch.
> 

That would be good.

Cheers

Russell