On Thu, 29 Mar 2012 15:22:28 -0400
Diego Novillo <dnovi...@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} ***

Reply via email to