MELT help: how to autoconf-igure makefile fragments?

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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