Re: [Boost-build] possible bug when cross compiling linux->windows

Subject: Re: [Boost-build] possible bug when cross compiling linux->windows
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-09-27 12:56:08

On Tuesday, September 21, 2010 21:03:31 Moritz Hassert wrote:
> Hi,
> 
> I know I'm digging up something old here but only now I found the time to
> investigate some more.
> 
> My current understanding:
> Steve is right, we can't just make all subfeatures optional. In fact I
> think it's the oposite: they all have to be non-optional, that is have to
> have a default value.
> The whole toolset configuration and usage depends on the fact that the
> first time a toolset is configured, all subfeatures of that toolset get
> defaulted to values that match that specific variant of the toolset. So if
> nothing is explicitly requested on the command line, this first
> configuration variant will be used.
> 
> If the version subfeature were optional, then putting the line
> using gcc ; in /etc/site-config.jam
> and doing
> "bjam toolset=gcc"
> would not work. One would always have to say
> "bjam toolset=gcc toolset-gcc:version=4.4.3"
> because toolset-gcc:version has no default value but the configured gcc has
> that version as a condition.
> 
> If the flavor subfeature is made optional, everything is fine on linux.
> Native configurations of gcc don't have that subfeature at all and
> therefore don't depend on it being set on the command line. For mingw
> cross compilers one has to explicitly add toolset-gcc:flavor=mingw. This
> is acceptable, because in this case the user is requesting something
> special, non-default, and therefore has to specify that. It's the only way
> to distinguish between a native gcc of the same version and the
> crosscompiler.
> 
> But on Windows with the flavor subfeature being optional and no default
> value assigned, one has to always add "toolset-gcc:flavor=mingw" to the
> command line. This is a thing you don't want to do when you're not cross
> compiling.
> 
> My current solution is to also assign a flavor on Linux.
> In gcc.jam I added a single line:
>          switch $(machine:L)
>          {
>              case *mingw* : flavor ?= mingw ;
> +            case *linux* : flavor ?= linux ;
>          }
> 
> 
> This works for me (although the build paths get even longer) but it just
> doesn't feel perfect :)
> 
> I'd like to get rid of the <flavor> completely and instead use <target-os>
> as the way to distinguish native from cross builds. Has anyone already
> done something along these lines?

[CCed for convenience, please reply to the list]

Moritz,

no, I don't think anybody has done this, yet. However, I think that using
target-os and dumping flavour is everybody's prefered solution. I think that
at least Rene, Jürgen and myself talked about this before.

The most clear formulation of the use cases is probably this:

        http://article.gmane.org/gmane.comp.lib.boost.build/19542/

I actually continue to think that default features might not be the solution.

We have, at least, the following properties that participate in selection of a
compiler binary:

        - target-os
        - architecture
        - toolset-gcc:version (well, I can never remember how it's spelled)

If we default them all -- for example to the first compiler, or to the host
compiler, then any change can potentially require changing all three.
This is because if you change target-os to say, AIX, even if you have
a compiler for that OS it might have different architecture and version,
and therefore if two other properties are left at default values, we'll
get inconsistency.

I think that given that toolchain is a fundemental part of Boost.Build,
we better handle this in a special way. For example, there's 
targets.common-properties function. We can, right at the start,
look at what values of the above properties are *explicitly* specified,
iterate over all defined toolsets, and pick those that match.

In theory, we can even add toolset property to the mix. So that, if
you specify

        bjam target-os=windows

and you have msvc configured in user-config.jam, it will get used.
This, however, requires that all properties involved in such special
selection do not have a default value, since otherwise by the
time we reach targets.common-properties, we don't know which
properties are explicitly specified by the user and which are defaulted.

What do you think?

- Volodya