From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21448 invoked by alias); 27 Nov 2001 22:41:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21343 invoked from network); 27 Nov 2001 22:40:55 -0000 Received: from unknown (HELO host140.cambridge.redhat.com) (195.224.55.237) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 22:40:55 -0000 Received: from localhost (bernds@localhost) by host140.cambridge.redhat.com (8.11.6/8.11.6) with ESMTP id fARMenC24640; Tue, 27 Nov 2001 22:40:49 GMT X-Authentication-Warning: host140.cambridge.redhat.com: bernds owned process doing -bs Date: Mon, 19 Nov 2001 10:59:00 -0000 From: Bernd Schmidt X-X-Sender: To: Ziemowit Laski cc: Stan Shebs , Ira Ruben , Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) In-Reply-To: <48173FB7-E386-11D5-AE62-0030658361CA@apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00898.txt.bz2 On Tue, 27 Nov 2001, Ziemowit Laski wrote: > On Tuesday, November 27, 2001, at 02:13 , Bernd Schmidt wrote: > > > Well, imagine we try to support not one, but fourty-two poorly designed > > extensions this way (and it would happen - everyone would go "hey, you > > did it for Altivec, why can't I put in my feature too"). Imagine trying > > to make any changes to the C parser if you have to make sure none of > > these > > patches break. > > No -- YOU DON'T have to make sure these patches don't break. THAT is the > responsibility solely of the authors/users of the patch in question. It sounded like you suggested the patch would be applied automatically during the build. In that case, the patch would have to be uptodate to prevent a build failure. If it isn't applied automatically and requires user intervention, you could just as well distribute it separately from gcc. > And yes, I would absolutely allow forty-two poorly designed extensions > to cohabit with the mainline compiler in this way. :) If you don't make it the C frontend maintainer's responsibility to keep them working, you'll end up with fourty-two non-working extensions pretty quick. Bernd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernd Schmidt To: Ziemowit Laski Cc: Stan Shebs , Ira Ruben , Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Tue, 27 Nov 2001 14:41:00 -0000 Message-ID: References: <48173FB7-E386-11D5-AE62-0030658361CA@apple.com> X-SW-Source: 2001-11/msg01399.html Message-ID: <20011127144100.riVgeqwdUAVxVSJzeGS0qyke54bxGaLzedHW0mATxlE@z> On Tue, 27 Nov 2001, Ziemowit Laski wrote: > On Tuesday, November 27, 2001, at 02:13 , Bernd Schmidt wrote: > > > Well, imagine we try to support not one, but fourty-two poorly designed > > extensions this way (and it would happen - everyone would go "hey, you > > did it for Altivec, why can't I put in my feature too"). Imagine trying > > to make any changes to the C parser if you have to make sure none of > > these > > patches break. > > No -- YOU DON'T have to make sure these patches don't break. THAT is the > responsibility solely of the authors/users of the patch in question. It sounded like you suggested the patch would be applied automatically during the build. In that case, the patch would have to be uptodate to prevent a build failure. If it isn't applied automatically and requires user intervention, you could just as well distribute it separately from gcc. > And yes, I would absolutely allow forty-two poorly designed extensions > to cohabit with the mainline compiler in this way. :) If you don't make it the C frontend maintainer's responsibility to keep them working, you'll end up with fourty-two non-working extensions pretty quick. Bernd