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

Subject: Re: [Boost-build] Built tools and cross compiling
From: Tom (tabsoftwareconsulting_at_[hidden])
Date: 2015-12-20 02:26:19

Steven Watanabe <watanabesj <at> gmail.com> writes:

> 
> AMDG
> 
> On 12/19/2015 05:56 PM, Tom wrote:
> > 
>   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.

Yes, in this case.  In the broader case, I want the requirements
specified explicitly on a target in the Jamfile to be used and not
those given on the command line.  This may not be a reasonable
expectation for Boost.Build.

> > <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).

This is probably good enough for this use case.  The main
problem I have right now is that the built tool ends up built
for the target platform unless I set it explicitly and I can't
do that in a cross platform way.  I actually am controlling
the user-config as well to keep the user' settings from
causing unexpected results.  The host toolset can be set there.

I'm currently doing two invocations ((1) host and (2) cross
platforms) to allow the user to build unit tests and simulations
with arbitrary properties. this, but with a built tool and a
cross-target interaction, that is no longer quite good enough.
A solution, though limited, would be very useful.

<snip>

> > 
> > 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?

I can't find fa54f3c.  Is that a commit in boostorg/build?

You are correct, everything works as it should for these
examples when a toolset is given on the command line, I
was mistaken.  Sorry for the noise, I must have been
confused.  I have been looking at several approaches
and may have confused the results.

Thanks again!
Tom