[Boost-build] Problem with mingw flavour

Subject: [Boost-build] Problem with mingw flavour
From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-10-30 16:28:03

Hi,

Jürgen has reported that if you have any mingw gcc 
configured in user-config.jam, then when building with any configured
version of gcc, you start to get 'mingw' in compiler name. I would
also assume that any condition testing for mingw would be evaluated to
true.

Furthermore, if you have this:

        using gcc : 4.2.4 ;
        using gcc : 4.2.4 : i586-mingw32msvc-g++ ;

and run 'bjam gcc', your command line starts to look like:

        "g++" "i586-mingw32msvc-g++" ...

What's happening is this, in gcc.init.

    if $(flavor)
    {
        condition = [ common.check-init-parameters gcc
            : version $(version)
            : flavor $(flavor)
            ] ;
    }
    else
    {
        condition = [ common.check-init-parameters gcc
            : version $(version)
            ] ;
    }

First time we run into mingw compiler, common.check-init-parameters creates
a subfeature for toolset=gcc, with a value of mingw. And that values becomes
default -- so it's applied for all invocations. When non-mingw compiler is
configured, the condition only involves version, so if mingw and native
compiler have the same version, we get funny results like two commands
above.

I can go about fixing this in various technical ways, but it's probably
best, first, to figure what behaviour we want. I'd imagine we want a few
different things

1. Be able to select the right compiler, by giving its version and some
properties.

2. Be able, inside Jamfile, to have conditional logic depending on
various compiler things.

3. Ideally, not explicitly specify, on command line, anything can
can be auto-detected.

One example is 'architecture' feature. This is clearly something that
is fully determined by the gcc binary -- I believe that it's just technically
impossible to create on gcc binary that would target two different architectures
at the same time. So, if I somehow select a compiler, the architecture feature
should be set automatically.

Now the question is which features should be the key for compiler selection,
and which should be deduced from the compiler. Consider:

        using gcc : 4.3.1 ; 			         # native (x86-linux) compiler
        using gcc : 4.3.1 : i586-mingw32msvc-g++ ; 	 # x86-windows compiler
        using gcc : 4.3.1 : arm-none-linux-gnueabi-g++ ; # cross to arm bare metal

The features involved are possibly:

        <toolset-gcc:version>
        <toolset-gcc:flavour>
        <target-os>
        <architecture>

I suggest we first deal with the flavour. It seems to me that it basically duplicates
<target-os> -- we can use <target-os>windows to detect the same, and for cygwin
compiler we'll have <target-os>cygwin. So, I suggest we drop this feature, and
use target-os instead.

The question of what features form primary key is tricky. 

1. If compiler is selected based on version alone, and target-os/architecture is set
from it, it means that we cannot have the same version in the example above. We probably
would need to have two versions -- specified by user, and the 'real version' reported by
compiler, which can be checked in Jamfiles.

2. If we also use target-os and/or architecture in compiler selection, it forces the user
to specify those properties, which is inconvenient. The upcoming configure mechanism
will make it required to specif those properties only once, but still -- is this OK?
Maybe it is, after all when cross-compiling auto* projects, one usually uses
--target=cpu-none-os. I'd imagine that if we can reliably detect architecture of the
current machine, and the architecture of the compiler, we can use host's architecture
as default.

I don't know what a really good interface would be. Ideas?

- Volodya