Re: [Boost-build] Problem with mingw flavour

Subject: Re: [Boost-build] Problem with mingw flavour
From: Juergen Hunold (juergen.hunold_at_[hidden])
Date: 2008-11-04 15:28:48

Hi Volodya !

On Monday 03 November 2008 21:06:10 Vladimir Prus wrote:
> On Friday 31 October 2008 11:42:20 Juergen Hunold wrote:
> > 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.

Yes, you are right. There are some debian gcc out there which support i386 and 
x64_86. I got confused by 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.

Fully agreed. This is indeed the worst case an should be avoided.

[snip my compiler configuration table]

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

Yes. We are on the same track here.

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

Yes.

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

Yes.

> 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

That would be great. 

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

Agreed, but note that example 3 suggests that 

   bjam  target-os=windows

should work because it matches the target-os of the "4.3mingw" compiler.
And this gives a nice short command, too :-))

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

Yes, this seems a hard one.

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

Agreed.

> 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

Well, I don't like it either. But this should work im my opinion because I'd 
like to simply write
         using gcc ;
        using gcc : : arm-none-eabi-g++ ;
and omit the toolset version and let  bjam figure it out for me. Thjs allows 
automatic adjustment to compiler upgrade and a minimal user-config.jam I can 
give to my colleagues.

But the rest sounds much better than the current behaviour.

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       !