Hello,
In the MELT branch, the cc1 program has (sometimes) to run a C compiler (usually the same gcc in the common case of
host=build=target=linux x86-64) to compile the MELT generated C code (which could be latter dlopen-ed by that cc1). This
means that sometimes, gcc-melt runs cc1 which may run a shell script which runs another gcc which produces a .so which
is dlopen-ed by the first cc1 ... Sounds crazy, but it is the way MELT is working (but it may not always happen: in
common use, gcc-melt runs cc1 which dlopen-s an existing .so - a MELT binary module without needing to run any process
to build it).
Up to revision 154660, that compilation (of the dynamically generated C file) was done by a shell script [expanded from
gcc/melt-cc-script.proto].
Now, I want to use make for that compilation. So now, gcc-melt runs cc1 which may run make which runs another gcc to
produce a .so which is dlopen-ed by the first cc1. The make is actually run as
make -f /some/path/to/melt-module.mk \
GCCMELT_MODULE_SOURCE=/a/second/path/to/melt-generated-c-file.c \
GCCMELT_MODULE_BINARY=/my/third/path/for/melt-binary-module.so \
GCCMELT_WORKSPACE=/a/scratch/directory/to/work/in/
[for the curious, everything is configurable at configure & at run time]
The point is that in the current revision 154683, the gcc/melt-module.mk [in MELT branch source tree] is not general
enough; I would like to have it expanded by autoconf from gcc/melt-module.mk.in, much like gcc/Makefile inside the build
tree is expanded from gcc/Makefile.in from GCC trunk's source tree.
But I don't understand much about gcc/configure.ac and I am extremely scared to
touch that file.
Does anyone have hints on what kind of stuff I should add to have a makefile fragment like [a future file]
gcc/melt-module.mk.in expanded into a melt-module.mk thru autoconf tricks?
BTW, you might have guessed why I so badly want libiberty to be usable, even from plugins (the MELT branch can be
compiled as a melt.so plugin if so wanted by retrieving a few files from the MELT branch). I really need the
pex_execute, pex_run, make_temp_file, xstrdup from libiberty, and in plugin mode I had to mimick these functions
painfully, poorly & unreliably, which is really a pity (and a loss of time). You might also understand why I would like
the plugin/ directory to be queriable from plugin code. Of course, MELT can live painfully without all these features...
you can use MELT as a plugin to an unmodified gcc-trunk installation...
Cheers.
--
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} ***
