This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc extensibility
On Thu, 29 Mar 2012 15:22:28 -0400
Diego Novillo <dnovillo@google.com> wrote:
> On 3/29/12 3:01 PM, Basile Starynkevitch wrote:
>
> > But I feel I don't wear the same hat as a plugin developer and as a GCC contributor.
>
> Yes, you do. You are both a GCC contributor and a plugin developer. As
> such, you are in a unique position to know the needs of both sides.
Well, I sort of agree, but I can't wear both hats *at the same time*. Either I feel as a
plugin developer, and then I struggle to make my plugin work with whatever versions of
GCC I have in mind, or I am a GCC contributor, and then I have to "forget" a bit my
plugin hat (of course keep "thinking" of my plugin needs). It is a bit like a kernel
developer who also develop a low level user-land application using his driver (imagine a
3D printer, or a computer-driven machining tool): when he develop the user-land thing
(imagine the 3D equivalent of CUPS, or a low-level CAD software for machining), he has to
aim some *existing* kernel version. Writing a plugin which would work only with an
experimental branch -and not with some GCC release, even a future one- is IMHO a complete
loss of time (and a huge but useless effort).
> Cleaning up the internal interfaces in the compiler may help plugin
> developers. Perhaps one thing you could help design and implement is a
> plugin-specific API that can evolve independently of the internal APIs
> in the compiler.
I am not sure to understand what you mean exactly. What is the plugin-specific API
(today, it is mostly the set of PLUGIN_* events, etc..). Or do you mean something else
which does not exist yet?
>
> Plugins that need pervasive access to compiler internals will need to
> evolve with it, and expect to need changes at every release of the
> compiler.
My feeling is that these "compiler internals" are actually the non-documented part of the
$(gcc -print-file-name=plugin/include) which today is the majority of the header files
there. Of course, I don't expect them to be stable. I do know they are not.
(And yes, sometimes these things bite and hurt).
> Others will be protected by the plugin-specific interfaces.
My feeling is that you think of the *documented* part of $(gcc
-print-file-name=plugin/include), that is the few things *documented* in
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
Or perhaps I (Basile) am misunderstanding you (Diego) entirely. Sorry for that if it is
the case!
>
> If we ever convert the compiler into a collection of self-contained
> libraries, then some of the things that today require plugins will be
> able to use these libraries directly.
I feel it almost the opposite way. When GCC becomes modular, it will be made of a
defined (and easily countable, i.e. a dozen or two) collection of libraries (each have to
be named! Names of modules [or libraries if you like this word] are important both to the
linker and to the developers (in particular the newbies). And a good picture of GCC would
be important too (recall the Gnome/GTK picture I mentioned many times).
The point is that I Basile sadly do not have the broad view and culture about GCC than
you (Diego, and other global reviewers) have. So I cannot even propose a set of module
names (or library names, if that hurts you less). Only people like you (Diego, and other
global reviewers) could propose -for discussion- a set of module (that is library) names.
I don't know GCC enough to think of one, sorry about that (I really mean it: I have
almost no idea of what the backends are made of, or of what the C++ or Ada or Go
frontends are made of).
Once GCC is defined by a set of modules (or libraries, for me a top-level module Foo is
implemented as a libfoo.so; exactly as in the Gnome world the Pango module is implemented
as libpango.so; so top-level modules are exactly implemented as shared-libraries), plugins
would have a well defined interface to it. Even, a plugin might replace exactly, or
supplement, an entire library (that would enable, for instance, providing a front-end or
a back-end as a plugin).
My feeling about a GCC modularity is that it would help *tremendously* if we have some
mechanical mean to describe -in details- that set of module. My feeling is that GTK could
teach us a lot about that (this does not mean that we should adopt GTK technology, just
that we should be inspired by GTK "philosophy" - but calling that a philosophy is an
insult towards the great philosophers like Socrate, Kant, etc...).
My dream -in particular because it would help MELT, and any language binding [Python,
Ruby, Ocaml, ...] to GCC- would be that GCC would have some meta-API, à la
http://live.gnome.org/GObjectIntrospection to query the set of modules and the large set
of API inside).
My other dream would be to have some plugins to help us (but sadly, I am not funded to
work on that; I would be delighted to be funded to use MELT for developping such MELT
extensions to help GCC) on that goal. It is quite sad that as a compiler community we use
so little compiler technology to help us work. There is a French wording about that: "les
coordonniers sont les plus mal chaussés", literally "shoe-repairers (or shoemakers) have
the worst shoes".
We (Diego & me) very probably agree a lot, but we very probably have linguistic or
cultural issues to understand each other. Sorry for my lack of fluency in English; it is
always hurting me.
Cheers.
--
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 mine, sont seulement les miennes} ***