Subject: Re: [Boost-build] Native-built tools in a cross-compile environment
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-10-23 16:25:38
On 10/23/2012 12:52 PM, Nogradi, Chris wrote:
> On Tuesday, October 23, 2012 2:37 PM, Steven Watanabe wrote:
>> The problem is in Boost.Build's handling of static libraries (In some
>> cases, static libraries can be propagated upwards too far):
>> I've made a reduced test case for this that works with any toolset.
>> I'm not exactly sure how to go about fixing it yet, though.
> I suppose my suggestion referenced below was not reasonable? Or maybe it is a different issue though it sounds similar?
It's basically the same issue, but your fix
is too specific to your problem.
The easiest generic fix is to add a feature attribute
saying that the feature should only be propagated
to immediate dependants when it's used in usage
requirements. It's probably necessary to mark
both <library> and <conditional> with this.
>> On 01/12/11 01:24, Nogradi, Chris wrote:
>>> 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 <link>shared in [ $(rproperties).raw ]
>>> raw = [ property.change $(raw) : <library> ] ;
>>> return [ $(result).add [ property-set.create $(raw) ] ] ;
> Thread references:
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