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

Subject: Re: [Boost-build] possible bug when cross compiling linux->windows
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2010-09-28 14:14:28

Hi,

> 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

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 
different things:
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 
toolset selection?

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.

Another point:
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.

Greetings
Moritz

-- 
--
AB+M GmbH 
Haid-und-Neu-Straße 7
76131 Karlsruhe
Telefon: [phone]
Telefax: (0721) 66488-18
Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845