Re: [Boost-build] Native-built tools in a cross-compile environment

Subject: Re: [Boost-build] Native-built tools in a cross-compile environment
From: Kylo Ginsberg (kylo_at_[hidden])
Date: 2012-10-23 18:32:21

On Tue, Oct 23, 2012 at 12:36 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> On 10/22/2012 05:03 PM, Kylo Ginsberg wrote:
>> Ok I spoke too soon.  That solution works *except* for the following:
>>
>> The tool is linked against static libraries, and I have a target
>> shared library which uses that tool.  For reasons I don't follow, the
>> cross build of that shared library ends up linking against *native*
>> versions of those static libraries.  Strange.
>>
>
> The problem is in Boost.Build's handling of
> static libraries (In some cases, static libraries
> can be propagated upwards too far):

Ok interesting.  And thanks for all the help!

> You can work around this with something like:
>
> class kill-usage-requirements : alias-target-class
> {
>     import property-set ;
>     rule compute-usage-requirements ( subvariant )
>     {
>         return [ property-set.empty ] ;
>     }
> }
>
> import project ;
> import targets ;
> rule my-alias ( name : sources + )
> {
>   return [ targets.create-metatarget kill-usage-requirements
>     : [ project.current ] : $(name) : $(sources) ] ;
> }
>
> my-alias text-to-c : text-to-c//text-to-c ;
>

Getting closer ....  The problem with this is it seems to throw out
the baby with the bathwater.  Specifically, both the native-built-tool
and the cross-built-target use the same library xxx.  When I add in
the logic above, the cross-built-target loses the include for the xxx
library, which is specified in a usage-requirements block.  (The
native build isn't effected in the same way apparently, which doesn't
make sense to me, but I also haven't dug into it yet.)

So ... ideas?  Should I hack on kill-usage-requirements so that it
only discards static libraries?  Or ...?

Thanks!
Kylo