Re: "plugin"-ifying the MELT branch.

[Basile STARYNKEVITCH <basile@starynkevitch.net>]

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!

Is there some [political?] impossibility for FSF copyrighted GPLv3 code 
(like those sitting in branches, e.g. the MELT one) to become plugins? I 
thought that becoming GPLv3/FSF plugins is an additional natural path 
for code sitting in branched to become accepted in the trunk!

I suppose these things has been discussed at the GCC summit a few days 
ago? What has been discussed & decided?

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 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).

Is there some new prohibition on FSF copyrighted GPLv3 licenced code 
(inside branches) providing plugins? Or did I (hopefully) misunderstood?

Can a branch only (or mostly) provide a plugin? If not, why? If a branch 
cannot provide a plugin, who, when was decided such a major decision? I 
feel such a decision fully in contradiction with the idea of accepting 
plugins in GCC.

Please take time to explain, and remember that I am not an English 
native speaker, that I am not familiar with the US law system or the 
American corporate culture, and that MELT branch was always designed 
with meta-programming & dlopening generated code in mind. MELT has 
absolutely no sense on system without dlopen (or an equivalent 
functionality. So far, MELT is using ltdl).

Regards.

Note *: the MELT branch always provided a plugin mechanism. It is 
essential to MELT to generate C code and run it. I always said that 
dlopen is essential to MELT

PS. My understanding of the runtime license exception discussion last 
year was that the FSF & the SC wanted to promote the idea of GPLv3 
licencsd plugins [and of course restrain proprietary plugins] not to 
discourage them (and rejecting the idea of FSF copyrighted GPLv3 
licenced plugins might not be perceived as encouraging GPLv3 plugins).

-- 
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} ***