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-19 19:56:55

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

> On 12/19/2015 06:46 AM, Tom wrote:
> > 
> > I have tried it that way and the result is that the built
> > tool ends up build for the target platform (see cross-final-b
> > below :)
> 
> What I meant was essentially cross-final-c.

I finally got there :)  Thanks!

Now, that you have helped me resolve this simple case, I have
a more complex case that I am trying to resolve.  I haven't yet seen
the light on how this really works.

> > However, given your response above, I tried a related approach
> > of setting the requirements on both the cross target and the built
> > tool target.  The cross-final-c target sets the built tool's
> > toolset to clang explicitly and sets a requirement on darwin for
> > cross-final-c.
> 
>   Setting clang on build_tool and using darwin on the
> command line should also work.

Yes, it does.

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.

> >  I did have to explicitly state the darwin version
> > to get the cross-built targets into the same directory (one went
> > into darwin-4.2.1 while the other went into darwin).  Do you know
> > why this would be the case?
> > 
> 
>   It's a bug.  targets.common-preoperties2 adds
> default values to the build request before
> handling the target's requirements.  As a
> result, the default toolset version isn't
> applied when the toolset is changed in the
> target requirements.

OK.

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

I am using Boost.Build to build real-time embedded systems, which have
constraints that should be locked down in the build system.  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.  These properties should not be
changed via the command line when building for these targets (though
can be when building unit tests, simulations, etc. for the host
platform).

Currently, I use a feature 'platform' to encapsulate this and use that
single property and switch between implementations.  I guess the
challenge with this approach is that I don't want to specify platform
for the host platform since I want the user to be able to control that
from the command line (or have it controlled implicitly by the host
platform, e.g. msvc vs. gcc vs. clang).  In most cases, this works as
I expect, but in this particular case of a built tool to operate on
target platform data, 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?

Generally, this has worked out very well (thanks to Boost.Build and
some help from this list!) and I've been using this approach for many
systems over the past 15 years or so.  It has proven very portable
across host platforms and targets alike.  I really haven't found any
better approach and I have implemented similar things in many other
systems (make, etc.) over many years.  There are still some minor
annoyances, hence this effort.

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

Thanks!
Tom