From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31924 invoked by alias); 16 Jun 2009 13:10:47 -0000 Received: (qmail 31914 invoked by uid 22791); 16 Jun 2009 13:10:46 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_73,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Jun 2009 13:10:37 +0000 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGYQs-00072P-KI for gcc@gcc.gnu.org; Tue, 16 Jun 2009 09:10:34 -0400 Received: (qmail 28332 invoked from network); 16 Jun 2009 13:10:33 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jun 2009 13:10:33 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1MGYQq-00026L-E2; Tue, 16 Jun 2009 13:10:32 +0000 Date: Tue, 16 Jun 2009 13:10:00 -0000 From: "Joseph S. Myers" To: Basile STARYNKEVITCH cc: Richard Guenther , GCC Mailing List Subject: Re: "plugin"-ifying the MELT branch. In-Reply-To: <4A378E9F.7020603@starynkevitch.net> Message-ID: References: <4A281366.9010004@starynkevitch.net> <4A377E77.3010807@starynkevitch.net> <84fc9c000906160416m26425ae0n81fd20510908f012@mail.gmail.com> <4A378033.3080504@starynkevitch.net> <4A378E9F.7020603@starynkevitch.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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/msg00360.txt.bz2 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). As already discussed at length, libltdl is liable to make building GCC and making effectively redistributable binaries without problematic dependencies much harder and so using it would be a bad idea. > 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). Making features presently supported by GCC optional and completely unavailable on many host platforms would be a clear regression. > > 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). The criterion for being appropriate to include in GCC is different from interesting every GCC user. Nothing interests every GCC user. > 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. If the feedback relates to the use of a particular library not provided by GCC, for example, that is probably an appropriate case for a plugin provided by that library rather than by GCC. If it is generally relevant to users of a particular language feature or feature in a language's standard library, like existing warnings in GCC, it is probably an appropriate case for code in GCC proper. > 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 I did not say anything about what branches should provide. My comments are about the question of whether feature X should go in trunk or in a separate plugin, given that there is an implementation that is or can be assigned to the FSF and that is technically ready to go in trunk. > This surprises me a big lot. I thought on the contrary that specialized > plugins would be used inside GCC in the future (for GCC development). To be > more concrete, one could imagine a plugin to check all the error & warning > messages inside GCC for validity (attribute printf is not fully adequate for > that purpose). And my interpretation of GTY as attribute discussion was that I could indeed imagine that those warnings that are present in GCC only for use when building GCC might usefully become plugins - but not without being able to build them in statically when bootstrapping on a platform on which plugins are not supported. This would be most useful if the plugins supported multiple host GCC versions so that the host GCC 4.5 building a 4.6 cross compiler could load the plugin for the version of checking relevant for building GCC 4.6. This is the special case above of code only useful for compiling one particular piece of software (where that one piece of software just happens to be GCC). > someone is dreaming to replace gengtype, in a distant future, by some plugin > providing the same behavior as gengtype (there is a bootstrap chicken&egg > issue in that case, but one could easily store the generated gt-*.h file in > the source tree, as it is already done for autoconf stuff today). It would be better to have fewer generated files in the source tree and fewer bootstrap dependencies or dependencies for modifying GCC and building a modified version, not more. (I also don't know what host and target dependencies those files might have.) Portable tools that can be built using any ISO C compiler are far better than depending on complicated host-specific features of a particular version of GCC. If we move to C++ as implementation language I believe we should keep the ability to build with non-GCC ISO C++ compilers and with a wide range of GCC versions. -- Joseph S. Myers joseph@codesourcery.com