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