This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "plugin"-ifying the MELT branch.
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} ***