Hello All,
This discussion is triggered by the one-line patch
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02227.html (I might have
already written some email on this in a different way). I believe it has
been at least informally discussed at the GCC summit a few weeks ago
(which I was not able to attend). So probably I am asking questions
about what has been already settled there!
I believe that the PLUGIN_HEADERS should be as complete as possible.
Alternatively, we might define a (small, strict, well-defined) subset of
GCC functions which are supposed to be callable from plugins (and hence
announcing a well defined GCC API) but I understood (at last year's
summit) that we don't want to (because that would ease proprietary
plugins) and that we are not able to define a stable GCC API (because
there is no such a beast).
The current situation is quite unsatisfactory (but I am aware that
plugins is still an experimental feature, and I am afraid that stage1
will close too soon to permit easy evolution!). A plugin writer may need
some GCC header file which is not yet in the PLUGIN_HEADERS variable of
gcc/Makefile.in (I call these headers listed there exported headers).
Hence, he either nearly always needs the entire source tree and build
tree of GCC (and that is IMHO a very costly requirement, contradictory
to plugins), or need (as I am trying to do) to push an additional file
(i.e. a one line patch) into the trunk to write his plugin.
My belief is that a plugin writer could (if he wants to) invoke any
function inside GCC which makes some sense at some occurrence of
invoke_plugin_callbacks in the trunk source. If you agree with that, the
plugin exported headers should contain every header included by every
trunk file calling invoke_plugin_callbacks.
The point is to compute this set of files, or alternatively to decide
that every GCC header should be exported.
If the host GCC compiler (ie the compiler which compiles GCC) is a
recent version of gcc, we might have some trick using gcc -MD to
determine this set. I did try something similar in the MELT branch, but
for some reason it breaks when --enable-multilib is configured (or
perhaps more generally on cross compilers).
Otherwise we need a strategy to decide what functions are *not* callable
from a plugin.
My short opinion is that PLUGIN_HEADERS should contain every GCC header
(but I don't know yet how to implement that). Do you agree on this goal?
[the alternative is many one-line patches]
If we still agree that there is no stable API inside GCC, I don't see
how we could avoid that. And the main argument against putting every
header file in the exported header set seems to be disk space, which is
not a big issue today (it seems to me that the total space of all GCC
header files is about 30Mbytes).
My feeling is that having the PLUGIN_HEADERS set evolve by small
one-line patches like
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02227.html is very
frustrating. If stage1 closes soon (or is it already closed), that means
that plugins won't be usable in gcc 4.5 but only later (ie in more that
one year), because I would expect that PLUGIN_HEADERS won't be permitted
to evolve in stage2 or stage3 (since increasing it is not a bug resolution).
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} ***
