plugin includes for MELT

[Basile STARYNKEVITCH]

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/Makefile.in parlance) 
$(DESTDIR)$(libexecsubdir)/melt-private-include/ and I should have some 
Makefile.in 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!

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