On 27 February 2008 12:57, Basile STARYNKEVITCH wrote: > My MELT branch [originally I called it basilys] is (currently is not but > should) generate C code during the cc1 execution
> 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 > 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 > 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 Does this matter? Any given compiler only has one combination of target and host; are you hoping the plugins will be swappable between differently-configured compilers? > * 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) It might be easiest to just generate a single pre-preprocessed .i file from run-basilys.h (using -dD) as part of building the compiler, and install it to the libexec include dir (or a 'melt/' subdir thereof, mightn't it? cheers, DaveK -- Can't think of a witty .sigline today....