This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "plugin"-ifying the MELT branch.
On Tue, Jun 16, 2009 at 2:22 PM, Basile
STARYNKEVITCH<basile@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.