Re: [Boost-build] Problem with mingw flavour

Subject: Re: [Boost-build] Problem with mingw flavour
From: Juergen Hunold (juergen.hunold_at_[hidden])
Date: 2008-10-31 04:42:20

Hi Volodya !

On Thursday 30 October 2008 21:28:03 Vladimir Prus wrote:
> 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.

That's the observation

> I would
> also assume that any condition testing for mingw would be evaluated to
> true.

Not tested, as I always use <target-os>windows,<toolset>gcc as it seems 
clearer to me...

[snip quote about toolset initialisation]
> 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

A quick workaround would be nice, so I can test with less hassle, but not 
necessary at the moment.

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

That would be great.

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

This depend on how "architecture" is defined. It is possible to build a linux 
gcc targeting both x86 and x86_64. The architecture is then defined by "-m32" 
and "-m64" flags. Ah sorry, that would then be "address-model" feature...
But it is extremely unlikely to build a toolchain supporting both windows and 
arm... 

> So, if I somehow select a
> compiler, the architecture feature should be set automatically.

That would be nice.

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

+1 from me.

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

Why ?  I can check 
<toolset>gcc:
<toolset>gcc,<target-os>windows
<toolset>gcc,<architecure>arm

for all three cases above. I can even specify the gcc-version in the checks.
Or am I missing something ?

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

Well, I think this is good enough. If I accidentially forget target-os=windows 
for mingw right now, bjam will happily run with host-os = target-os = linux 
and mingw g++ will bail out because it groks on -pthread...

If I have the same gcc for host and cross compiling (did not manage to get to 
this point with pre-built mingws ;-)) you can drop the toolset=gcc-4.3.2 and 
have to only specify target-os=windows. So this is straight forward.

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

What I'm missing is the "address-model" feature. Right now, we have:

feature.feature address-model : 16 32 64 : propagated optional ;

and also "propageted optional" for "architecture".
It would be great if we could remove the "optional" and set some sensible 
defaults. Example for a default setup:
g++ -dumpmachine architecture address-model target-os
x86_64-suse-linux  x86 64 linux
i486-linux-gnu x86 32 linux
i586-mingw32msvc x86 32 windows
mingw32 x86 32 windows
 x86_64-pc-mingw32 x86 64 windows
i386-mingw32 x86 32 windows

Those are all I can find right now :-))

That would set sensible defaults even for a simple "using gcc ;".
Right now, I don't now the default for "address-model" because there is none 
for optional features. This makes it quite hard to specify requirements 
depending on "address-model".

Hope this makes my intention clear.

Yours,

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold       ! Ingenieurgesellschaft für 
* voice: ++49 511 262926 57       ! Verkehrs- und Eisenbahnwesen mbH  
* fax  : ++49 511 262926 99       ! Lister Straße 15
* juergen.hunold_at_[hidden]        ! www.ivembh.de
* 
* Geschäftsführer:                ! Sitz des Unternehmens: Hannover
* Prof. Dr.-Ing. Thomas Siefer    ! Amtsgericht Hannover, HRB 56965
* PD Dr.-Ing. Alfons Radtke       !