From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26964 invoked by alias); 15 Jan 2012 22:21:10 -0000 Received: (qmail 26955 invoked by uid 22791); 15 Jan 2012 22:21:09 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from tirion.supremecenter202.com (HELO tirion.supremecenter202.com) (209.25.195.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Jan 2012 22:20:57 +0000 Received: from c-e01ee155.46-4-64736c11.cust.bredbandsbolaget.se ([85.225.30.224]:60299 helo=[192.168.0.197]) by tirion.supremecenter202.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RmYRa-0005nh-Qs for ecos-devel@ecos.sourceware.org; Sun, 15 Jan 2012 22:20:55 +0000 Message-ID: <4F135141.9030908@siva.com.mk> Date: Sun, 15 Jan 2012 22:21:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00018.txt.bz2 On 15.01.2012 19:42, 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) > > % 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 > > 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? It seems there have been some attempts before as there are some traces left in gcc tree: gcc/config/arm/ecos-elf.h I'm not sure about former addition, But IMO that it would be good to add t-ecos target description(s). The material is present in eCos patches ftp://ecos.sourceware.org/pub/ecos/gnutools/src/ . Speaking of branding, we shouldn't omit --version banner (|--with-pkgversion|), let's say "eCos community edition []" >> Are the eCos sources going to start requiring use of specific >> toolchain binaries? > Nope. Anyone can use own binaries if he/she wants. We must be sure of this. People will need, from various reasons, to use different toolchains (commercial or self built). Ilija