From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ecos-devel-return-1965-listarch-ecos-devel=sources.redhat.com@ecos.sourceware.org>
Received: (qmail 19043 invoked by alias); 15 Jan 2012 18:42:21 -0000
Received: (qmail 19034 invoked by uid 22791); 15 Jan 2012 18:42:20 -0000
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com) (209.85.214.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Jan 2012 18:42:07 +0000
Received: by bkcjg15 with SMTP id jg15so3446585bkc.20        for <ecos-devel@sources.redhat.com>; Sun, 15 Jan 2012 10:42:06 -0800 (PST)
Received: by 10.205.127.141 with SMTP id ha13mr1087026bkc.28.1326652926033;        Sun, 15 Jan 2012 10:42:06 -0800 (PST)
Received: from vostro ([178.123.111.134])        by mx.google.com with ESMTPS id ek9sm3030924bkb.10.2012.01.15.10.42.04        (version=TLSv1/SSLv3 cipher=OTHER);        Sun, 15 Jan 2012 10:42:05 -0800 (PST)
Date: Sun, 15 Jan 2012 18:42:00 -0000
From: Sergei Gavrikov <sergei.gavrikov@gmail.com>
To: Grant Edwards <grant.b.edwards@gmail.com>
cc: ecos-devel@sources.redhat.com
Subject: Re: Gnutools: consideration for upgrade to GCC 4.6
In-Reply-To: <jev2q2$s4a$1@dough.gmane.org>
Message-ID: <alpine.DEB.2.00.1201152053580.4856@vostro>
References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> <alpine.DEB.2.00.1201141854480.2289@vostro> <jev2q2$s4a$1@dough.gmane.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-IsSubscribed: yes
Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <ecos-devel.ecos.sourceware.org>
List-Subscribe: <mailto:ecos-devel-subscribe@ecos.sourceware.org>
List-Post: <mailto:ecos-devel@ecos.sourceware.org>
List-Help: <mailto:ecos-devel-help@ecos.sourceware.org>, <http://ecos.sourceware.org/lists.html#faqs>
Sender: ecos-devel-owner@ecos.sourceware.org
X-SW-Source: 2012-01/txt/msg00016.txt.bz2

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)

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