Re: Gnutools: consideration for upgrade to GCC 4.6

[Grant Edwards <grant dot b dot edwards at gmail dot com>]

On 2012-01-15, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov@gmail.com> 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)

I realize it would distinguish official toolchains from others.  What
I want to know is why that's useful.

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

That doesn't seem to be appropriate to me.  In eCos builds, the
include files are not part of the toolchain and their locations
shouldn't be determined based on the toolchain.  The eCos include
files are part of the eCos source tree and build system (which
provides __ECOS__).

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

For one thing, I use the same toolchain to build eCos stuff and
non-eCos stuff.  The __ECOS__ macro can be used to tell the
difference.

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

Not if eCos code is going to contain checks for __ecos__ that cause a
build to fail without __ecos__.

>> I've been using eCos for a long time, and have always used my own
>> toolchains.  I'd be pretty unhappy if that was no longer possible.
>
> Why it will be not possible? I did not understand.

If the eCos code is going to be checking for __ecos__ then that code
won't build with my toolchains.

> You can use own, but, a bug reporter should/may use officially
> supported "labeled" toolchain to check the roots of some issue on
> crashes. But, naturally, I do not resists on built-in label __ecos__.
> Look on that as a promotion eCos OS. If you think that my points are
> wrong, please, forget it.

As long as nothing in the build process checks for or requires
__ecos__, then that's fine.

-- 
Grant Edwards               grant.b.edwards        Yow! Hey, wait
                                  at               a minute!!  I want a
                              gmail.com            divorce!! ... you're not
                                                   Clint Eastwood!!