From: Jurko GospodnetiÄ (jurko.gospodnetic_at_[hidden])
Date: 2008-08-24 06:57:52
> Thanks for your quick answer, yes you're right for i'm using the
> use-project rule in order to get access to the jamfile defining this
> library target. And actually i lied a bit saying that it was in order to
> build an exe because it would have been that i could have had install
> the library in the exe jamfile. My problem is that it's not an exe but a
> unit-test and so i the dll is not install just after being compiled the
> unit-test is ran and can't load the dynamic library. does it make sense
> for you ?
OK, let me check if I understood you correctly. No solution yet...
You have Jamfile A which defines two targets:
my-lib - for building a library
my-lib-dist - for installing the built library.
with my-lib-dist obviously depending on my-lib.
Then you have Jamfile B which defines a my-test unit-test target
depending my-lib. That target when built is run by Boost Build
automatically after being built and requires the built my-lib library to
Note that I do not have much experience with Boost Build's
unit-testing support so I might get something wrong here. :-)
I've taken a look at the source code now and here are some ideas I
get for a working quick-fix:
* As mentioned in the previous post - use the my-lib-dist install
target as your source for my-test. This will depend on some questionable
internal Boost Build behaviour but could work.
* Use the testing.launcher property to specify a script for running
your executable and have it copy the source library file to the correct
location or add the library's location to the system library search path.
Hmmm, also in tool/testing.jam that implements Boost Build's unit
testing framework there is an interesting rule run-path-setup that seems
to be related to what you need. Judging by its comment framework is
supposed to have already taken care of adding the library to the system
path. Perhaps you can debug the problem from there and see whether this
gets called and if yes then why it does not seem to fix the problem.
Although, I guess how I can see a need for specifying a general Boost
Build action to be executed before running a unit-test so it could
implement any custom setup the test might need. Perhaps you could look
into that after you fix the problem at hand. ;-)
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk