Re: [Boost-build] Install question

Subject: Re: [Boost-build] Install question
From: Ian Emmons (iemmons_at_[hidden])
Date: 2011-11-02 09:12:29

On Oct 24, 2011, at 1:10 PM, Ian Emmons wrote:
> 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?

I have found an answer to my own question, which I'd like to share, and in the process I've found an error in the documentation.

What I discovered is the following:

Recap of what I knew before:  When a unit-test target (on Windows) depends on a DLL via a searched-lib target, Boost.Build adds to the path environment variable of the test executable the <search> feature from the requirements of the searched-lib target.  This allows the test executable to find the DLL.  This path modification is not necessary on UNIX, because the shared library paths are hard-coded within the test executable by the linker.

What I've learned recently:  When a unit-test target (on Windows) depends on a DLL via an alias target, Boost.Build ignores any <search> feature on the alias target.  However, it does add to the path environment variable of the test executable the <dll-path> feature, taken either from its own requirements or from the usage requirements of the alias target.

Documentation bug:  All reference to the <dll-path> feature in the Boost.Build manual indicate that this feature affects only UNIX/Linux compilers.  As I stated above, this is not true.  The feature is used in a completely different way on Windows, but it is in fact used.

Thanks again for the suggestion to use an alias target!