Re: [jamboost] <hardcode-dll-paths>true as default

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-14 04:00:13

Toon Knapen wrote:

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

BTW, current "stage" relinks all executables, this behaviour is specifically 
needed so that when staging, you can set the <dll-path> -- which too 
hardcodes dll path, but only to a value specified by the user.

And we should be doing the same for libraries, I think. Because staging the 
library may involve change in the name, and shared library can be renamed 
without relinking -- otherwise, the 'soname' encoded inside the library will 
be different from the real name.

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

This is a dilemma I don't know how to solve. It's desirable to have the same 
behaviour on all platforms, but then I've said "use <hardcode-dll-paths>true" 
too many times.

I even though that V2 should be producing scripts which run the binary with 
the right library path (just like libtool does not Linux), but that's very 
nasty solution.

- Volodya