plugin includes for MELT

Basile STARYNKEVITCH basile@starynkevitch.net
Wed Feb 27 12:57:00 GMT 2008


Hello All,

{sent to the gcc@ mailing list and Bcc- to GlobalGCC partners}

This email is related to the plugin includes question 
http://gcc.gnu.org/ml/gcc/2008-02/msg00373.html 
http://gcc.gnu.org/ml/gcc/2008-02/msg00376.html within (in particular) 
the MELT branch http://gcc.gnu.org/ml/gcc/2008-02/msg00256.html
http://gcc.gnu.org/ml/gcc/2008-02/msg00355.html
http://gcc.gnu.org/wiki/MiddleEndLispTranslator
funded thru the GGCC http://ggcc.info/ ITEA http://itea2.org/ project

My MELT branch [originally I called it basilys] is (currently is not but 
should) generate C code during the cc1 execution from some LISP dialect 
(either in memory, or in *.bysl files); the generated C code is then 
compiled as a plugin into a shared object which is dynamically loaded 
thru dlopen (actually thru lt_dlopenext from <ltdl.h> - the libtool 
dynamic loader wrapper). I don't care much about the perennity of the 
generated *.c or *.so files; they might need to be regenerated when 
bumping the gcc version (from 4.4 to 4.5 for example)

The point is that every MELT generated C file is a plugin to the 
middle-end hence depends upon all the middle-end stuff notably tree.h 
and many many others.

In its current (sad & buggy) state, MELT is not able to work without a 
GCC build and source trees (and I am using scripts which I uploaded to 
the Wiki page)! This is not acceptable, it should be able to run on a 
system without any of them (but of course some additional files, 
describing the internals of GCC used by MELT plugins, are required)

Practically, every MELT generated file has exactly one include directive:
   #include "run-basilys.h"
the gcc/run-basilys.h is in the MELT branch and of course include many 
other files eg
   #include "config.h"
   #include "system.h"
   #include "coretypes.h"
   #include "tree.h"
   #include "target.h"
   #include "cgraph.h"
   #include "ipa-prop.h"
   #include "tree-flow.h"
   #include "tree-pass.h"
   #include "flags.h"
   #include "timevar.h"
   #include "diagnostic.h"
   #include "tree-dump.h"
   #include "tree-inline.h"
   #include "compiler-probe.h"
   #include <ppl_c.h>
   #include <ltdl.h>
   #include "basilys.h"

So far, my thoughts about all this is:

* some of the *.h are host- specific, but many are target- specific and 
I have hard time to understand which files exactly are host- specific
and which one are target- specific

* some of the *.h are generated, hence in the build tree (not in the 
source dir from SVN)

* disk space is cheap, but huge -I... include options are messy so I am 
thinking of having a single *generated* directory, e.g. in the build 
directory include/gcc-melt-plugin-$(host)--$(target) which is later 
installed in $(DESTDIR)$(includedir)/gcc-melt-plugin-$(host)--$(target)/ 
and which contains all the relevant *.h files needed to run-basilys.h 
(directly or indirectly included by it)


Does all the above make sense?


My understanding (which is poor regarding the gcc/Makefile.in) is that 
sys-include/ is not relevant in this discussion

Regards.

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



More information about the Gcc mailing list