From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13947 invoked by alias); 16 Jan 2012 15:20:51 -0000 Received: (qmail 13932 invoked by uid 22791); 16 Jan 2012 15:20:47 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Jan 2012 15:20:33 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RmoLg-0006ru-R3 for ecos-devel@sources.redhat.com; Mon, 16 Jan 2012 16:19:52 +0100 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jan 2012 16:19:52 +0100 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jan 2012 16:19:52 +0100 To: ecos-devel@sources.redhat.com From: Grant Edwards Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 Date: Mon, 16 Jan 2012 15:20:00 -0000 Message-ID: References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: slrn/pre0.9.9-102 (Linux) X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00021.txt.bz2 On 2012-01-15, Sergei Gavrikov wrote: > On Sun, 15 Jan 2012, Grant Edwards wrote: > >> On 2012-01-14, Sergei Gavrikov 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 - #define __rtems__ 1 > > and the same we could have for officially supported releases for ecos, > e.g. > > % i386-ecos3.12-gcc -dM -E - #define __ecos__ 1 > > Secondly, it lets anyone to use such checks in sources, e.g. > > #if __linux__ > # include > #elif __ecos__ > # include > #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!!