From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6865 invoked by alias); 16 Jun 2009 12:53:11 -0000 Received: (qmail 6743 invoked by uid 22791); 16 Jun 2009 12:53:10 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_50,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-qy0-f194.google.com (HELO mail-qy0-f194.google.com) (209.85.221.194) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Jun 2009 12:53:04 +0000 Received: by qyk32 with SMTP id 32so5728503qyk.0 for ; Tue, 16 Jun 2009 05:53:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.97.210 with SMTP id m18mr5550107vcn.50.1245156782391; Tue, 16 Jun 2009 05:53:02 -0700 (PDT) In-Reply-To: <4A378E9F.7020603@starynkevitch.net> References: <4A281366.9010004@starynkevitch.net> <4A377E77.3010807@starynkevitch.net> <84fc9c000906160416m26425ae0n81fd20510908f012@mail.gmail.com> <4A378033.3080504@starynkevitch.net> <4A378E9F.7020603@starynkevitch.net> Date: Tue, 16 Jun 2009 12:53:00 -0000 Message-ID: <84fc9c000906160553s40880203q33480aa8e25d2a21@mail.gmail.com> Subject: Re: "plugin"-ifying the MELT branch. From: Richard Guenther To: Basile STARYNKEVITCH Cc: "Joseph S. Myers" , GCC Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2009-06/txt/msg00356.txt.bz2 On Tue, Jun 16, 2009 at 2:22 PM, Basile STARYNKEVITCH wrote: > > I (Basile) very probably misunderstood what Joseph Myers or Richard Guenther > meant. What I might have [mis]understood scares me. This is a request for > clarification. > > > Joseph S. Myers wrote: > > >> On Tue, 16 Jun 2009, Basile STARYNKEVITCH wrote: >> >> >>> >>> I thought on the contrary that is was expected that some code would >>> become FSF >>> owned plugins? >>> >> >> Not without a mechanism for linking plugins in statically on hosts for >> which we don't support dynamic loading of plugins, and even then it's >> doubtful. > > That mechanism already exists in libltdl (the libtool wrapper of dlopen). > > However, I am not sure to understand the logic here. Plugins are by > definition optional stuff, and I understood from the beginning that plugins > are considered only on machines which have a way of dynamically loading code > (currently, the documented constraint is even stronger: dlopen & -rdynamic). > >> Rather, we should watch out for things being implemented as plugins that >> are generally useful for GCC and seek to build them into GCC >> (unconditionally) where appropriate, while leaving cases such as checking >> project-specific coding rules as separate plugins. > > Again, I don't understand the rationale here. > > My broad feeling was that plugin feature is for code which could interest > some people, but does not interest every GCC user. (and MELT, or even ICI or > TreeHydra, fits the definition). > > In particular, there would probably be several plugins which give some extra > feedback to the developers using them, but do not modify the code generation > behavior of GCC. > > Did I understood that in your view no branch hosted on GCC SubVersion should > provide plugins? Why? Is it only your view, or some decision by some > powerful guys (e.g. the Steering Committee)? Did the MELT branch [*] > suddenly become illegal without me knowing about that? That would be > ironical for a branch which happened -with other branches & people- to have > pushed the idea of plugins! As you already said, a plugin is not a branch of trunk and so it should not be a branch of trunk. There is no way a user with usual SVN write access can (or should) add a new repository to host a plugin on gcc.gnu.org. Instead I suggest that plugins be hosted at whatever convenient public repository hosting site. Just because it does not make technical sense. No "powerful" entities are involved here. Richard.