Re: [Boost-build] Install question

Subject: Re: [Boost-build] Install question
From: Ian Emmons (iemmons_at_[hidden])
Date: 2011-10-24 13:10:22

On Oct 14, 2011, at 4:01 AM, Vladimir Prus wrote:
> On Thursday, October 13, 2011 21:22:08 Ian Emmons wrote:
>> Forgive me if I'm treading on old ground here, but I can't figure out how
>> to make "install" do what I want, and the documentation only takes me so
>> far.
>> 
>> A short statement of my problem:  An install rule, with the
>> "<install-dependencies>on" feature setting, will install the designated
>> executable and all of its dependent DLLs built within the same project,
>> but will not install dependent DLLs designated by searched-lib targets.  I
>> need it to install both.
> 
> ...
> 
>> Is there a way to get an install target to do what I want?
> 
> I am afraid the answer is "no". searched libraries are those found
> via the -L and -l options to the compiler, and therefore at no
> point Boost.Build even tries to figure where those libraries are.
> Using actual library files will allow you to do what you want, e.g.
> using:
> 
> 	alias foo : libfoo.so ;
> 
> Does this help?

This does help -- a lot.  Thanks for the suggestion.

Using this trick, I've gotten almost everything to work on Macintosh, Ubuntu Linux, and Windows.  My exe and dll targets work on all three platforms, but I have a unit-test rule as well, and while that works on Mac and Linux, it does not on Windows.  The problem is that the unit test executable can't find the DLLs that it depends on.  This isn't a problem on Mac and Linux, because the locations of these dependencies are baked into the executables by the linker itself.  But on Windows, this isn't the case.  So, my question is this:

When a unit-test target (on Windows) depends on DLLs via searched-lib targets, how does the unit-test target find those DLLs during the actual testing?  And how can I imitate the same mechanism when I substitute aliases for the searched-libs?

Thanks,

Ian