On Tue, Jun 16, 2009 at 2:22 PM, Basile STARYNKEVITCH<bas...@starynkevitch.net> 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.
