From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25222 invoked by alias); 16 Jan 2012 20:43:37 -0000 Received: (qmail 25210 invoked by uid 22791); 16 Jan 2012 20:43:36 -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; Mon, 16 Jan 2012 20:43:22 +0000 Received: by bkcjg15 with SMTP id jg15so4311875bkc.20 for ; Mon, 16 Jan 2012 12:43:21 -0800 (PST) Received: by 10.205.120.148 with SMTP id fy20mr5542195bkc.125.1326746601284; Mon, 16 Jan 2012 12:43:21 -0800 (PST) Received: from vostro ([178.123.66.178]) by mx.google.com with ESMTPS id ig13sm9749998bkc.9.2012.01.16.12.43.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 12:43:20 -0800 (PST) Date: Mon, 16 Jan 2012 20:43:00 -0000 From: Sergei Gavrikov To: Grant Edwards cc: ecos-devel@sources.redhat.com Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 In-Reply-To: Message-ID: References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> 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: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00022.txt.bz2 On Mon, 16 Jan 2012, Grant Edwards wrote: > 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__). I agree, snippet above does confuse most of you. I would defend it, but, I do not want to do so as I do not desire to change the *Subject* of this thread. (I'm sorry Ilija) > > For now we usually add '-D__ECOS__' to CFLAGS for some packages. To be clear, I did not offer neither to remove nor replace -D__ECOS__ from CFLAGS in eCos config files. I'm sorry if you've seen this. > > 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 ever did not think about. I did not plan to implant such checks in *eCos sources*. I did not say, we should s/__ECOS__/__ecos__/g. I 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. > >> 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. Once again that was not attempt of any revisionism for eCos sources. IMHO, built-in CPP definition (__ecos__) can be useful a) for portable userland applications (not eCos sources); b) for shell scripts which would detect toolchain easier; c) to distinguish home cooked or third party toolchains from eCos stable ones (that was my main idea). I risk to paste yet another check /* * NOTE: I do not offer such a check for eCos sources itself. */ #ifdef __ECOS__ # if !defined(__ecos__) # warn Used wrong toolchain for mission critical application. # BUG() # endif #endif But. Can such check exist in userland application? [Not need to answer] > > 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. I hope I have convinced you and Stano that I did not suggest to "close" eCos sources by __ecos__ checks. More that to propagate that built-in definition is only a few lines for GCC patch and if that is issue I am ready to withdraw my "I like their built-in" :-) Let's move on to the subject of the thread. It seemed for me that all of us are interested in new toolchain(s) and if you are the experts here, let's open Bugzilla entry for this, there we would accumulate a set of patches for new toolchain base. Sergei > -- > Grant Edwards grant.b.edwards Yow! Hey, wait > at a minute!! I want a > gmail.com divorce!! ... you're not > Clint Eastwood!! >