Boost logo

Boost-Build :

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


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