From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-05-19 02:06:04
Larry Evans wrote:
> Yep, I tried it and it works.
> Thanks Vladimir.
> IMO v2/boost_build_v2.html#using_libraries would be clearer if it
> mentioned this requirement right after the code snippet, as follows.
> exe app : app.cpp ../lib/lib1//lib1 ;
> In addition, the project requirements needs "<hardcode-dll-paths>true".
I think some clarification would be needed.
> However, I also see that:
> Further, only gcc compiler supports this option.
> yet, the location:
> When this property is on, usage requirements for each library will
> include additional dll-path propertry, with the path the the generated
> library file. This allows to run executables without placing all the
> dependent libraries to a single location.
> which doesn't mention gcc. Which is correct?
Ok, let me try to explain all this mess. When <hardcode-dll-paths> is
When <hardcode-dll-paths>true is specified when building a library, V2 takes
the path to the library it creates (it surely knows the paths) and adds it to
<dll-path> usage requirements.
So, when main application is linked, it has a lot of <dll-path> properties,
listing location of all needed libraries.
The <dll-path> property is handled in somewhat different ways:
1. On Unix, it's included into the binary. So, the resulting binary can be
2. On Windows, the operating system does not provide comparable mechanism so
we do nothing.
That's not the end of the story, though. The above behavious will break
regression tests on Windows, so *when running tests* the values of <dll-path>
are added to environment variable which specifies search paths for libraries.
So, the "run" rule works everywhere.
The "unit-test" rule was created much earlier than "run" and is much simpler
-- it does not include the same logic and therefore really works only on
If that answers your question, I'll try to revise the docs accordingly.
> BTW, I think this documentation is a lot clearer than previous docs I
> read (several months ago).
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