Subject: Re: [Boost-build] possible bug when cross compiling linux->windows
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2010-09-28 14:14:28
> 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
> 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
I agree that compiler selection should not be based on default values set when
the first compiler is configured. In my opinion the whole problem stems from the
fact that defining features and their values during toolset configuration is a
somewhat upside down approach.
A specific compiler incarnation should be configured to depend on two very
a) condititions that specify what this compiler is used for
(target-os, architecture, address-model, ...)
b) features that destinguish it from others of the same type, that is other
compilers that match a)
(toolset name, toolset-XXX:version)
Configuring a compiler toolset should just say "IF all those a)-type conditions
are met, you may use me" but not introduce new features that the rest of the
system did not know about until then. b)-type conditions are only used to
choose among more than one applicable toolset.
I fully agree with your usage examples. Thats exactly what I had in mind.
Whether the whole thing would work without default values, I can't say. I must
admit, I don't fully understand your implementation approach because of a lack
of insight into the boost build guts. I'll try to find the time to digg deeper.
Would properties that are not explicitly specified be assigned a value during
The reason why I ask:
The question arises what to include in the build path and what not. In my
case, doing a lot of cross-compiling, I would like to have everything in the
build path. For example, I force the address-model property to be the host's
one when not cross-compiling because otherwise I end up compiling into the
same directory when using a network share and switching between a linux64 and
a linux32 host. On the other hand, a user that never leaves the windows/msvc
world could be annoyed always having the extra
"/target-os-windows/architecture-x86/address-model-32/" in the build path.
Right now, the toolset _selection_ happens by assigning a value to the
variable $(CONFIG_COMMAND) when the conditions of the toolset are met.
So if none of the configured toolsets matches, $(CONFIG_COMMAND) is empty and
the compile actions try to run an empty command making the first argument the
command. This results in strange errors instead of a clear "NO MATCHING
COMPILER" error. So the current implementation decides to use the gcc toolset
despite the fact that none of the available incarnations match. I'm not sure
what would happen if more than one toolset matches.
A redesign of the toolset configuration and selection system should include a
more sane way of checking and error handling.
-- -- AB+M GmbH Haid-und-Neu-Straße 7 76131 Karlsruhe Telefon: (0721) 66488-0 Telefax: (0721) 66488-18 Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp Amtsgericht Mannheim HRB 105845
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