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:
> 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
> 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
> 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]
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:
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
- 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
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
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?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk