From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28758 invoked by alias); 29 Mar 2012 16:42:47 -0000 Received: (qmail 28671 invoked by uid 22791); 29 Mar 2012 16:42:45 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Mar 2012 16:42:31 +0000 Received: by obbwc20 with SMTP id wc20so1610223obb.20 for ; Thu, 29 Mar 2012 09:42:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.108.97 with SMTP id hj1mr44554650obb.37.1333039350418; Thu, 29 Mar 2012 09:42:30 -0700 (PDT) Received: by 10.182.92.168 with HTTP; Thu, 29 Mar 2012 09:42:30 -0700 (PDT) In-Reply-To: <20120329182704.eac67e3f9b2955ab8a0d81de@starynkevitch.net> References: <67CC0396-E15D-40DB-ACEB-613FE521FCFB@gmail.com> <20120329182704.eac67e3f9b2955ab8a0d81de@starynkevitch.net> Date: Thu, 29 Mar 2012 16:42:00 -0000 Message-ID: Subject: Re: gcc extensibility From: Gabriel Dos Reis To: Basile Starynkevitch Cc: Romain Geissler , =?ISO-8859-1?Q?Niels_M=F6ller?= , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00482.txt.bz2 On Thu, Mar 29, 2012 at 11:27 AM, Basile Starynkevitch wrote: > On Thu, 29 Mar 2012 11:06:11 -0500 > Gabriel Dos Reis wrote: > >> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler >> wrote: >> > Hi >> > >> > Le 29 mars 2012 =E0 14:34, Niels M=F6ller a =E9crit : >> > >> >> 1. I imagine the plugin API ought to stay in plain C, right? >> > >> > I don't know if this was already discussed and if the community >> > ended up with a clear answer for this question. If it's not the case >> > i would prefer a plugin interface in C++, for the same reasons it >> > was decided to slowly move the internals to C++. >> > >> >> I do not think people working on plugins have come up with a >> specification and an API they agree on. > > > I believe plugin makers (if you can count me amongst them) don't have at = all this > approach. By definition, a plugin should work with whatever interface a g= iven GCC release > makes available. Plugins people by definition cannot alter or improve the= interface that > GCC is giving to them (otherwise, they are no more plugins people, but GC= C contributors). I suspect that if plugins people want to make progress on this recurring theme, they will have to come up with a specification and an API. Otherwise, they have= only themselves to blame if their plugins break from release to release. -- Gaby