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