Re: [Boost-build] Built tools and cross compiling

Subject: Re: [Boost-build] Built tools and cross compiling
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-12-19 22:17:31

AMDG

On 12/19/2015 05:56 PM, Tom wrote:
> 
> However, setting darwin on cross-final-c and using
> clang on the command line does not (everything is built with darwin).
> I guess this makes sense since there are no requirements on the built
> tool it uses the requirements from cross-final-c.  However, this is the
> way I'd like to specify it since the cross target must be built with darwin
> but the built tool can be built with any toolset for the host.  I try to explain
> why below.
> 

  So, let's see if I understand correctly.  You
want the command line toolset (aka clang) to mean
the host toolset, with the cross compiler (aka darwin)
being hard-coded in the Jamfile?  This is
tricky.

>>> This is similar to what what I tried in my more complicated project
>>> and it did not work.  The difference was that in my project, I
>>> am using a new feature called platform to drive the requirements
>>> on targets built for the cross-platform.  I also do not want to explicitly
>>> state the host platform's requirements since I'd like to build using
>>> several different host platforms.
>>
>>   What is the difference between platform and
>> host-os/target-os?
> 
> <snip>I am
> using the term 'platform' to describe the minimum build properties of
> the target system.  A platform might then include the target-os,
> toolset, the toolset version, the instruction set, inlining, exception
> handling, optimization level, etc.  <snip>
> 

Okay.

> <snip> I don't have anything to put as the requirement
> on the built tool for the host platform such that I get the desired
> effect.
> 
> There is probably a better term for this, but target-os doesn't
> capture it.
> 
> How would you recommend going about this?
> 

  Would it be sufficient for your use case simply to
reset the toolset and all related features to their
default values for built_tool, completely ignoring
both the command line and the explicitly specified
cross-compiler?  I know this isn't perfect, but it's
easy to implement, and if it's good enough, it's probably
not worth the difficulty of somehow propagating the
command line toolset through.  (The default means
that you'll use the first toolset defined in any
config file).

> 
>>>  Do you have an idea how this can
>>> be done in this example project?  I don't want to modify the built
>>> tool's definition as it is correct (it has no requirements on anything
>>> but that stated).  However, an alias for the built tool with an explicit
>>> requirement on the host platform (or in this case, clang) might do
>>> the trick.  What do you think?
>>>
>>
>> Yes, than should work.
> 
> I've given it a try and I don't think this (or anything else I've tried) does
> what I want.  I can always seem to cause the cross target to be built
> with properties that are incompatible with what I'm trying to express.
> For instance, putting a toolset on the command line causes the cross
> target to be built with that toolset even though it is not
> <toolset>darwin-4.2.1.  Is it clear what I'm trying to say / do?
> 

  That doesn't sound right.  I thought that
properties specified on specific targets
override the command line.  Is this with
fa54f3c?  Does it happen for all of cross-final-a/b/c
or just some of them?

In Christ,
Steven Watanabe