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