Re: [Boost-build] Remove <flavor>mingw from gcc

Subject: Re: [Boost-build] Remove <flavor>mingw from gcc
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2014-04-10 08:59:35

Hi Steven, hi all,

Am Montag, den 07.04.2014, 10:27 -0700 schrieb Steven Watanabe:
[...]
> I propose simply removing this behavior.
[...]
> Any objections?

I cannot comment on consequences for the Boost tree itself but I
currently rely on the flavor for our own projects. So while I find the
current mechanism rather imperfect please don't just remove it
completely. Instead, how about replacing it with something better?

My current use-case:
On my Ubuntu machine I use my system's default compiler (gcc-4.8) for
native compiling and two kinds of mingw (32bit and 64bit, both version
4.6) for cross compiling.

My user-config.jam looks like this:
---
using gcc ;
using gcc :  : x86_64-w64-mingw32-g++  ;
using gcc :  : i686-w64-mingw32-g++ ;
---
To use the native compiler, I just run:
"b2"
For cross compiling to Windows 64-bit I run:
"b2 toolset=gcc-4.6 toolset-gcc:flavor=mingw64 target-os=windows
address-model=64"
This is awkward in several ways:
1) I have to specify the version (4.6), because otherwise boost-build is
looking for a mingw compiler with the same version as the native
gcc(4.8).
2) I extended tools/gcc.jam, adding the following two lines to the
flavor logic:
            case i?86*mingw* : flavor ?= mingw32 ;
            case x86_64*mingw* : flavor ?= mingw64 ;
As an alternative, I could have added "<flavor>mingw64" and
"<flavor>mingw32" in user-config.jam.
Otherwise both compilers get the flavor "mingw" which leads to an error.
3) Both "toolset-gcc:flavor=mingw64" and "target-os=windows" are
basically saying the same thing. One should be enough. I prefer
"target-os=windows" because I find it more intuitive.
So i propose to make the logic for mingw in gcc.init depended on the
host OS:
a) When on Windows, don't add any extra conditions. After all, mingw is
kind of the "native gcc" for Windows. No need to explicitly specify the
<target-os> and using the (implicit) address-model of the installed
mingw should normally be ok.
b) When NOT on Windows (e.g. Linux): 
  - Add <target-os>windows to the toolset conditions.
  - We're cross compiling, so there is really no sense in implicitly
using the "default address-model" of the host. Therefore auto detect the
address-model of the mingw at hand and add <address-model>XY to the
default build options. Make it default build options and not build
requirements, so that one can override the value for a multilib-enabled
mingw.
  - Add a way in user-config.jam to add <address-model>XY (or arbitrary
features values) to the toolset conditions (not build options!).
Another thing not directly related to <flavor>:
In my opinion toolset selection is somewhat surprisingly different to
target alternative handling:
When two alternatives for one target exist, the one with best matching
feature values is chosen.
So in a situation where linux gcc is the default toolset and only one
mingw is configured, I would expect that
"b2 <flavor>mingw64"
would select the gcc toolset with flavor mingw regardless of its version
and the version of the native gcc as long as it's the only one perfectly
matching "<flavor>mingw". Why do I need to specify its version?
Greetings
Moritz
Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845