This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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/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} ***