Re: Gnutools: consideration for upgrade to GCC 4.6

On 15.01.2012 19:42, Sergei Gavrikov wrote:
> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov<[email protected]>  wrote:
>>
>>> By the way I like their built-in __rtems__ definition for own GCC builds
>>> and I guess in the end we would propagate __ecos__ for own ones on the
>>> occasion of renewal.
>> Why?
> Simply to distinguish the official releases of toolchains (I hope well
> tested) and any home-cooked toolchains. I meant such predefined things
> for GCC (CPP)
>
>    % i386-rtems4.11-gcc -dM -E -</dev/null | grep __rtems__
>    #define __rtems__ 1
>
> and the same we could have for officially supported releases for ecos,
> e.g.
>
>    % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
>    #define __ecos__ 1
>
> Secondly, it lets anyone to use such checks in sources, e.g.
>
>    #if __linux__
>    # include<endian.h>
>    #elif __ecos__
>    # include<machine/endian.h>
>    #else
>    ...
>    #endif
>
> For now we usually add '-D__ECOS__' to CFLAGS for some packages.
>
> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?

It seems there have been some attempts before as there are some traces 
left in gcc tree:
gcc/config/arm/ecos-elf.h

I'm not sure about former addition, But IMO that it would be good to add 
t-ecos target description(s). The material is present in eCos patches 
ftp://ecos.sourceware.org/pub/ecos/gnutools/src/ .

Speaking of branding, we shouldn't omit --version banner 
(|--with-pkgversion|), let's say "eCos community edition [<ver>]"

>> Are the eCos sources going to start requiring use of specific
>> toolchain binaries?
> Nope. Anyone can use own binaries if he/she wants.

We must be sure of this. People will need, from various reasons, to use 
different toolchains (commercial or self built).

Ilija