This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: plugin includes for MELT

Hello All,

Dave Korn wrote:
On 27 February 2008 18:26, Basile STARYNKEVITCH wrote:

  So, since you are planning to compile the plugin during cc1 execution
anyway, why not just say that

- plugins are distributed as source

Yes, exactly. And to be more precise, all MELT plugin C code is generated (from some MELT Lisp code). This leaves the GCC API dependency to the generating stuff.

Of course I have to deal with the dependency of the MELT Lisp code on the GCC internals, but about this I have some ideas about (basically stay at the highest level possible).

 - the compiler keeps the gcc-private headers in its private libexec include
subdir, thus automatically making the correct headers go along with the
correct version+host+target compiler

I think it should be (in gcc/ parlance) $(DESTDIR)$(libexecsubdir)/melt-private-include/ and I should have some trick to copy the relevant *.h there perhaps thru a install-melt-includes target

 - when cc1 runs, it compiles any plugins needed (possibly caching the
compiled objects in another libexec subdir) and dlopens them.

Then, as you gain experience with MELT and it becomes clearer to you which parts of gcc's internal api are stable enough to be exposed, you can gradually build up to a public, SDK-like header file, which exposes only those details of the internals that you are either confident enough will not change, or that you feel would not be too difficult to provide a backward-compatibility shim layer for if they do change.

Yes exactly. But this SDK-like header does not really exist. all the coding in MELT is done in Lisp (and some of this Lisp code would change as GCC evolves).

Actually, my current concern is just the part of MELT which translates LISP into C (the warm-basilys.bysl file, coded in my Lisp dialect, and [almost] able to translate itself into C), and as you might guess this part does not depend much on all the (unstable) GCC API, just on a more stable subset (mostly ggc.h basilys.h and the fact that tree [and some very few others GCC types] are "opaque" pointers).

Actually the whole MELT idea is to separate as much as possible stuff heavily depending on GCC unstable API to those depending on more stable stuff (like ggc.h & basilys.h):
the MELT translator warm-basilys.bysl and the MELT related runtime basilys.c does not depend much on GCC unstable API. For instance, it does know about tree typename, but does not care about the details of tree.h. Regarding tree-s (in GCC sense) it only depends upon the fact that tree is a GGC-ed pointer.

more specific stuff are other files (mostly to be written still)

Dave a big thanks for your insights & help. It was unvaluable!

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]