Hello All,
To make MELT more interesting & more easy to use, I want to make it
become a (big & meta *) plugin. I also need to document & illustrate it
much more. I actually did start to work on the pluginification of MELT:
I mean making MELT a real GCC plugin, not needing any core GCC patch
anymore. The current snapshot (rev148175 of the MELT branch) already
have some call to register_callback (with PLUGIN_GGC_MARK, so I don"t
need to hack the GGC collector anymore.), even if MELT is not yet a real
plugin.
I think that would be doable once gengtype is able to work in plugin
mode, i.e. once the
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00410.html patch is
accepted into the trunk (or an equivalent way of doing it). AFAIK, once
such a facility is provided, I could make MELT a plugin quite easily (by
dropping some minor MELT functionalities, probably the compiler probe
and the libtool support - ie using dlopen instead of the lt_dlopenext
wrapper.
This brings some questions.
Can a branch be simply a plugin, or should I close (soon) the
melt-branch and start a melt-plugin-branch on the SVN. If I do that, do
I need some authorization? from whom?
Will there be a list of FSF-owned plugins (outside of the trivial ones
for testing)? MELT could be an example of a non-trivial FSF plugin.
Perhaps we need on the SVN an additional class of sub-repositories. Not
only branches and the trunk (and old releases) but also plugins....
I won't be able to attend the summit this year.
Regards.
Note *: MELT is a meta plugin in the sense that it generate C code,
compile it, and dynamically load it. However, the MELT generated plugins
do not follow the plugin API; they have their own ones!
--
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} ***
