Subject: Re: [Boost-build] EXE linking with DLLs
From: Vladimir Prus (ghost_at_[hidden])
Date: 2011-12-02 08:05:43
On 01/12/11 01:24, Nogradi, Chris wrote:
> Thanks Matt!
> I did not have opportunity to try your suggestion out yet since it would require me to re-architect many jam files. What I ended up doing is to modify targets.jam line 1421 like so:
> # TODO - Actually there are more possible candidates like for instance
> # when listing static library X as a source for another static library.
> # Then static library X will be added as a<source> property to the
> # second library's usage requirements but those requirements should last
> # only up to the first executable or shared library that actually links
> # to it.
> local raw = [ $(subvariant).sources-usage-requirements ] ;
> raw = [ $(raw).raw ] ;
> raw = [ property.change $(raw) :<pch-header> ] ;
> raw = [ property.change $(raw) :<pch-file> ] ;
> # remove libraries from shared link targets
> if [ $(rproperties).get<link> ] = shared
> raw = [ property.change $(raw) :<library> ] ;
> return [ $(result).add [ property-set.create $(raw) ] ] ;
> which seems to do what I want but is probably not the right solution for all.
> I suppose it would be better to remove<library> for exe and shared link targets but I did not know how to do that. Maybe someone is willing to educate me?
the code that adds <library> in the first place is inside builtin.jam, around line 919. There's also
comment explaining why it works this way. To be honest, I am not longer sure why example in the
comment makes sense :-(
Can you remind what is the problem with linking additional static libraries to the application? Is
this performance, or you get link errors as the result?
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