Re: [jamboost] hardcode-dll-path, Unit-Test Pseudotarget?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-29 02:41:46

Hi Peter,

peter_schoen1_web_de wrote:

> I am currently learning boost.Build and have a few questions:
>
> 1. I tried to get boost.Build to hardcode (-rpath) a prebuilt lib
> into an executable:
>
> lib boost-unit-test
>
> : <name>boost_unit_test_framework
>
> <search>/somePath/threading-single
>
> : <include>/somePath/boost_1_30_0
>
> <dll-path>/somePath/threading-single
> <library-path>/somePath/threading-single
> ;
>
> I noticed that both <search> as well as <library-path> add a "-L" flag
> to the linker's command line. What's the difference between the two?

I think the fact that you should not use <library-path> ;-) IIRC, V2 inherited 
<library-path> from V1. One day, we've invented <search> property which 
allows to specify searched libraries in the same way as ordinary ones. 
<library-path> has no user value now, AFAIK.

> <dll-path> seems to trigger the -rpath option. If dll-path is not set,
> but <library-path> is set, no -rpath option is generated. Is that
> intended?

Yep. <dll-path> specify the path which will be used at runtime to search for 
dynamic libraries --- essentially -rpath switch. The <library-path> has no 
relation with it.

> 2. Is there a global pseudotarget that I can use in order to run all
> the unit tests in a project tree? "bjam test" or "bjam tests" didn't
> work.

Nope. There was fuzzy plans for such feature (global targets), but nobody 
implemented them. And, actually, nobody even designed them.

- Volodya