|
Boost-Build : |
From: Jürgen Hunold (hunold_at_[hidden])
Date: 2004-10-15 01:15:02
Hi !
On Thursday 14 October 2004 10:11, Toon Knapen wrote:
> Vladimir Prus wrote:
> > When working on Linux, the <hardcode-dll-paths>true is almost
> > always what user wants. This allows to run binaries which use
> > dynamic libraries without changing LD_LIBRARY_PATH or installing
> > the libraries to system locations. What about making "true" value
> > the default, and stop telling the user about <hardcode-dll-paths>?
+1 from my side. On Linux, it is quite hard to develop without
<hardcode-dll-paths>on ;-))
> > The only case where it's not needed is when installing the
> > binaries, so we'd need the "stage" rule to use
> > <hardcode-dll-paths>false unless user has explicitly asked
> > otherwise.
+1 , too.
> > Thoughs?
> but won't this risk to compile everything twice (or at least link
> everything twice since the hardcode-dll-path features is only of
> importance to the link stage)?
>
> If you have a jamfile that defines a library target and a stage rule,
> first the library will be generated with the hardcoded paths. Next
> the stage target will copy the library but requires a library without
> hardcoded paths and thus requires to link the library again. This
> might be unexpected behaviour too.
Well, actually the paths are code into the *application*. And the stage
rule actually relinks the exe.
> From a multi-platform point of view (which bjam tries to achieve),
> since harcoded paths are not available everywhere, I would not use
> them by default.
But coding without it is a real PITA. mmh.
I've set _all_ my projects to use it when available.
And on Win32 we link static, so paths don't matter ;-))
It would be great if msvc would provide something like gcc...
Yours,
Jürgen
-- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold_at_[hidden] ! www.ive.uni-hannover.de
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