Boost logo

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...



* 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] !

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at