Re: [Boost-build] Problem with mingw flavour

Subject: Re: [Boost-build] Problem with mingw flavour
From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-11-03 15:06:10

On Friday 31 October 2008 11:42:20 Juergen Hunold wrote:
> 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...

Well, architecture is defined as "subdirectory in the 'config' directory in
the gcc source" (32-bit intel and AMD64/EMT are handled by i386 subdir).
I believe gcc configure magic does not allow to build with two architectures at
all.

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

Rene, do you have a comment on this?

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

I mean that Boost.Build needs some way to select from 3 available compilers.
If the selection process uses only the version, and no other properties, then
you would have to write;

        using gcc : 4.3.1native ;
         using gcc : 4.3.1mingw : i586-mingw32msvc-g++ ;
         using gcc : 4.3.1arm : arm-none-linux-gnueabi-g++ ;

which does not sound very nice.

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

Well, I think that we need to have architecture and address-model properties
always set, so that Jamfiles could check them. We could either set their
values, by default, to host's architecture, or we can guess them from toolchain.

Let me try to work the right behaviour from some examples:

Example 1.

        using gcc : 4.1 ;
        using gcc : 4.3 : my-custom-g++ ;

Here, first one should be used built by default. During build, architecture,
and address-model should be set.

Example 2.

        using gcc : 4.3 ;
        using gcc : 4.1 : arm-none-eabi-g++ ;

I would think that

        bjam architecture=arm 

should work. User should not have to specify version explicitly. Also

        bjam toolset=gcc-4.3 architecture=arm

should give an error.

Example 3.

        using gcc : 4.3 ;
        using gcc : 4.3 : arm-none-eabi-g++ ;

I think that

        bjam architecture=arm 

should also work, as well as:

        bjam toolset=gcc-4.3 architecture=arm 

Example 4:

        using gcc : 4.3native ;
        using gcc : 4.3mingw : i585-mingw32msvc-g++ ;

Assuming I'm on Linux, should

        bjam toolset=gcc-4.3mingw

work (setting target-os to windows), or fail? I think it should
fail, because it seems that

        bjam toolset=gcc-4.3 target-os=windows

is more straightforward way to express the same.

Example 5:

        using gcc : 4.3 ;
        using gcc : 4.3 : arm-none-linux-g++ ;

Assuming I'm on Windows, should

        bjam target-os=linux

work (setting architecture to arm), or fail? I don't really know,
but probably we should not be very smart, and fail.

So, we start with toolset version, architecture and target-os,
and just find the toolset that matches all of that, else we fail.

The only problem is with example 2, to recall:

        using gcc : 4.3 ;
        using gcc : 4.1 : arm-none-eabi-g++ ;

Now, the default toolchain version would be 4.3, and if user writes

        bjam architecture=arm target-os=eabi

then default toolchain version will be applied (4.3), and no toolchain
will match. I'm not sure I like the idea to say:

        bjam toolset=gcc-4.3 architecture=arm target-os=eabi

Comments?

- Volodya