* Re: [plugin] Directory for plugins distributed with gcc [not found] <fe7fd8170907151130j35ac3348kb447e7e1d273d9af@mail.gmail.com> @ 2009-07-15 18:43 ` Diego Novillo 2009-07-15 18:51 ` Olatunji Ruwase 0 siblings, 1 reply; 9+ messages in thread From: Diego Novillo @ 2009-07-15 18:43 UTC (permalink / raw) To: Olatunji Ruwase; +Cc: gcc [ Moved to gcc@ ] On Wed, Jul 15, 2009 at 14:30, Olatunji Ruwase<tjruwase@google.com> wrote: > Has any decision being made on how plugins will be distributed with > future releases. Is there going to be a plugins directory ?. > Thanks We may want to produce some plugins that are useful for GCC development and distribute them with the compiler, but in general I don't think we should get in the habit of incorporating 3rd party plugins in GCC. This would be detrimental to one of the useful properties of plugins (i.e., less code we need to maintain). I set up a landing page where projects can register their plugins (http://gcc.gnu.org/wiki/plugins). My suggestion is to use that page as the central plugins directory, with the assumption that we (GCC) are not the maintainers of those packages. We simply provide a link to them. Diego. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 18:43 ` [plugin] Directory for plugins distributed with gcc Diego Novillo @ 2009-07-15 18:51 ` Olatunji Ruwase 2009-07-15 19:14 ` Diego Novillo 0 siblings, 1 reply; 9+ messages in thread From: Olatunji Ruwase @ 2009-07-15 18:51 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc Sorry that I wasn't very specific with my question. I m currently wrapping up the conversion of mudflap into a plugin. Most of the required patches have being approved and committed, so I was thinking ahead as to where the the plugin code will reside. Thanks for the information and the link tunji On Wed, Jul 15, 2009 at 11:43 AM, Diego Novillo<dnovillo@google.com> wrote: > [ Moved to gcc@ ] > > On Wed, Jul 15, 2009 at 14:30, Olatunji Ruwase<tjruwase@google.com> wrote: > >> Has any decision being made on how plugins will be distributed with >> future releases. Is there going to be a plugins directory ?. >> Thanks > > We may want to produce some plugins that are useful for GCC > development and distribute them with the compiler, but in general I > don't think we should get in the habit of incorporating 3rd party > plugins in GCC. This would be detrimental to one of the useful > properties of plugins (i.e., less code we need to maintain). > > I set up a landing page where projects can register their plugins > (http://gcc.gnu.org/wiki/plugins). My suggestion is to use that page > as the central plugins directory, with the assumption that we (GCC) > are not the maintainers of those packages. We simply provide a link > to them. > > > Diego. > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 18:51 ` Olatunji Ruwase @ 2009-07-15 19:14 ` Diego Novillo 2009-07-15 19:36 ` Joseph S. Myers 2009-07-16 13:09 ` Rafael Espindola 0 siblings, 2 replies; 9+ messages in thread From: Diego Novillo @ 2009-07-15 19:14 UTC (permalink / raw) To: Olatunji Ruwase; +Cc: gcc On Wed, Jul 15, 2009 at 14:50, Olatunji Ruwase<tjruwase@google.com> wrote: > Sorry that I wasn't very specific with my question. I m currently > wrapping up the conversion of > mudflap into a plugin. Most of the required patches have being > approved and committed, so I was > thinking ahead as to where the the plugin code will reside. Ah, this is a different issue. What you are proposing is to take mudflap out of GCC and convert it into a separate plugin. I don't really have a strong opinion on mudflap in particular. I wouldn't mind making it a plugin, though. What do other folks think? In general I think spinning off modules/passes that are not used very frequently (e.g. the tree browser) is a good idea since it reduces the size of our code base. Diego. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 19:14 ` Diego Novillo @ 2009-07-15 19:36 ` Joseph S. Myers 2009-07-15 20:43 ` Paolo Bonzini 2009-07-16 13:09 ` Rafael Espindola 1 sibling, 1 reply; 9+ messages in thread From: Joseph S. Myers @ 2009-07-15 19:36 UTC (permalink / raw) To: Diego Novillo; +Cc: Olatunji Ruwase, gcc On Wed, 15 Jul 2009, Diego Novillo wrote: > In general I think spinning off modules/passes that are not used very > frequently (e.g. the tree browser) is a good idea since it reduces the > size of our code base. Before moving something out to a plugin (if we think that is technically appropriate for the particular code in question) we should have a way to build code, set up to be built as a plugin, into the compiler so that the -fplugin options find the built-in code, in a way that does not depend on plugins otherwise being supported on the host system; maybe somewhere in the source tree to put sources for plugins that get built into the compiler, or a configure option to point to such sources. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 19:36 ` Joseph S. Myers @ 2009-07-15 20:43 ` Paolo Bonzini 2009-07-15 20:53 ` Joseph S. Myers 0 siblings, 1 reply; 9+ messages in thread From: Paolo Bonzini @ 2009-07-15 20:43 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Diego Novillo, Olatunji Ruwase, gcc On 07/15/2009 09:36 PM, Joseph S. Myers wrote: > Before moving something out to a plugin (if we think that is technically > appropriate for the particular code in question) we should have a way to > build code, set up to be built as a plugin, into the compiler so that the > -fplugin options find the built-in code, in a way that does not depend on > plugins otherwise being supported on the host system; maybe somewhere in > the source tree to put sources for plugins that get built into the > compiler, or a configure option to point to such sources. It would be easy to switch from libdl to libltdl (which is independent from libtool, and can be built as a host module from the toplevel makefile), and use libtool -dlpreopen if this is desired. Paolo ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 20:43 ` Paolo Bonzini @ 2009-07-15 20:53 ` Joseph S. Myers 2009-07-15 21:16 ` Basile STARYNKEVITCH 2009-07-15 21:43 ` Paolo Bonzini 0 siblings, 2 replies; 9+ messages in thread From: Joseph S. Myers @ 2009-07-15 20:53 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Diego Novillo, Olatunji Ruwase, gcc On Wed, 15 Jul 2009, Paolo Bonzini wrote: > On 07/15/2009 09:36 PM, Joseph S. Myers wrote: > > Before moving something out to a plugin (if we think that is technically > > appropriate for the particular code in question) we should have a way to > > build code, set up to be built as a plugin, into the compiler so that the > > -fplugin options find the built-in code, in a way that does not depend on > > plugins otherwise being supported on the host system; maybe somewhere in > > the source tree to put sources for plugins that get built into the > > compiler, or a configure option to point to such sources. > > It would be easy to switch from libdl to libltdl (which is independent from > libtool, and can be built as a host module from the toplevel makefile), and > use libtool -dlpreopen if this is desired. Unless libltdl can be statically linked in, using it is a bad idea for other reasons as previously discussed at length. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 20:53 ` Joseph S. Myers @ 2009-07-15 21:16 ` Basile STARYNKEVITCH 2009-07-15 21:43 ` Paolo Bonzini 1 sibling, 0 replies; 9+ messages in thread From: Basile STARYNKEVITCH @ 2009-07-15 21:16 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Paolo Bonzini, Diego Novillo, Olatunji Ruwase, gcc Joseph S. Myers wrote: > On Wed, 15 Jul 2009, Paolo Bonzini wrote: > > >> On 07/15/2009 09:36 PM, Joseph S. Myers wrote: >> >>> Before moving something out to a plugin (if we think that is technically >>> appropriate for the particular code in question) we should have a way to >>> build code, set up to be built as a plugin, into the compiler so that the >>> -fplugin options find the built-in code, in a way that does not depend on >>> plugins otherwise being supported on the host system; maybe somewhere in >>> the source tree to put sources for plugins that get built into the >>> compiler, or a configure option to point to such sources. > > Unless libltdl can be statically linked in, using it is a bad idea for > other reasons as previously discussed at length. > > I am aware of these reasons (but I am not sure to agree with them; however, that is not my point here) against libltdl. A possible trick would be to decide a convention, such as a plugin whose name starts with a dot, or contains a slash, is in fact a "builtin" plugin, always available (and its code is part of GCC core). Actually, there is a reason to do so, if some GCC code wants to use some plugin facility. For instance, the MELT branch, even when compiled as a branch (i.e. without being compiled as a plugin), does call register_callback internally. And currently, code can call register_callback without any plugin being actually loaded in. There is no check on the plugin name argument to register_callback. Such a convention (on builtin plugins) does not need to be implemented by code. It could be just agreed upon and suitably documented. A side effect of this would be perhaps to limit extra GCC -f... program flags, since we could make them as plugin flags to builtin plugins. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 20:53 ` Joseph S. Myers 2009-07-15 21:16 ` Basile STARYNKEVITCH @ 2009-07-15 21:43 ` Paolo Bonzini 1 sibling, 0 replies; 9+ messages in thread From: Paolo Bonzini @ 2009-07-15 21:43 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Paolo Bonzini, Diego Novillo, Olatunji Ruwase, gcc On 07/15/2009 10:47 PM, Joseph S. Myers wrote: > Unless libltdl can be statically linked in, using it is a bad idea for > other reasons as previously discussed at length. I know of no program that dynamically links to libltdl, actually. Paolo ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [plugin] Directory for plugins distributed with gcc 2009-07-15 19:14 ` Diego Novillo 2009-07-15 19:36 ` Joseph S. Myers @ 2009-07-16 13:09 ` Rafael Espindola 1 sibling, 0 replies; 9+ messages in thread From: Rafael Espindola @ 2009-07-16 13:09 UTC (permalink / raw) To: Diego Novillo; +Cc: Olatunji Ruwase, gcc > In general I think spinning off modules/passes that are not used very > frequently (e.g. the tree browser) is a good idea since it reduces the > size of our code base. I would go a bit further. One nice properties of plugins is that they have a more restrictive API. That should help us to get the code a bit more maintainable. Olatunji's work is a very nice example. For example, to make mudflap a plugin he had to remove the occurrences of "if (flag_mudflap)" and make mudflap use the existing generic varpool. > > Diego. > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-07-16 13:09 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <fe7fd8170907151130j35ac3348kb447e7e1d273d9af@mail.gmail.com> 2009-07-15 18:43 ` [plugin] Directory for plugins distributed with gcc Diego Novillo 2009-07-15 18:51 ` Olatunji Ruwase 2009-07-15 19:14 ` Diego Novillo 2009-07-15 19:36 ` Joseph S. Myers 2009-07-15 20:43 ` Paolo Bonzini 2009-07-15 20:53 ` Joseph S. Myers 2009-07-15 21:16 ` Basile STARYNKEVITCH 2009-07-15 21:43 ` Paolo Bonzini 2009-07-16 13:09 ` Rafael Espindola
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).