From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-12 05:09:13
Rene Rivera wrote:
> [2002-11-10] Vladimir Prus wrote:
>>Rene Rivera wrote:
>>Okay.. I seem to understand this better now, thanks. One more question on
>>is there a way to hardcode the path to shared library in exe? I want it in
>>order to avoid setting LD_LIBRARY_PATH when debugging, when libraries live
>>in build directories.
> Yes, you can, and this is what I do in my projects for debug binaries also.
> In V1 I have this set for all my targets:
> <gcc><linkflags>"-Wl,-rpath -Wl,."
> <gcc><linkflags>"-Wl,-rpath -Wl,$(GCC_STDLIB_DIRECTORY)"
Good. I think if we both need this feature, we can create a new feature for
it, something like <hardcode-dll-paths>?
>>>Yes, that would be a good way to get both uses. In fact it might be
>>>to specify that for each source in the stage. Basically allowing to
>>>symlinks in the stage to arbitrary other targets.
>>Nice idea. We'd need a mechanism for specifying different processing for
>>different sources, though.
> Any ideas on how to do that? I'll think about it.
You see, now we have
exe a : a.cpp mylib/<optimizaton>off ;
but this specified which variant of "mylib" to select, while what we
want is different processing for different sources. Maybe we can
extend this mechanism. If <use-symlinks> is incidential property
(the one which is assumed to not affect build products) then
stage dist : mylib/<optimization>off/<use-symlink>yes ;
would select the same variant of "mylib" as
stage dist : mylib/<optimization>off ;
However, we can make <use-symlink> somehow travel with the generated
target, so that stage rule can take care of it. It's not trivial.
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