This is the mail archive of the gcc@gcc.gnu.org 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]

plugin includes for MELT


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


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