On Sun, 15 Jan 2012, Grant Edwards wrote: > On 2012-01-14, Sergei Gavrikov <sergei.gavri...@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) % 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? > Are the eCos sources going to start requiring use of specific > toolchain binaries? Nope. Anyone can use own binaries if he/she wants. > 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. 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. Thanks for your comments. Sergei > Grant > > > >
