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-10-04 03:57:29

On Tuesday, September 28, 2010 22:14:28 Moritz Hassert wrote:
> 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.

Yeah, that's right.

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

I think so. In particular, if 'architecture' and 'address-model' are not set 
automatically it means you cannot easily use them in conditional properties.

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

I guess this is independent issue. On one hand, it would be nice if 
address-model is always set to some value. On the other hand, the problem
you mention is real, but can be solved by some indepentend mechanisms --
including omitting 'architecture' and 'address-model' strings from the path
and merging some properties -- so you'll get windows-x86-32, for example.

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

I suppose gcc.jam or other toolset modules would not need much changing.
I'd imagine that each gcc.init call will communicate to build system something
that "there's new toolset, with toolset=gcc toolset:gcc-version=4.4 target-
os=windows architecture=x86". Then the build system core will guarantee that
if this toolset is chosen, all those properties will be in in build 
properties. Therefore, the toolset only have to make sure that those 
properties are in conditions for all flags and generators, and that's it.

- Volodya