status of GCC 4.5 w.r.t. plugins?

[Basile Starynkevitch <basile at starynkevitch dot net>]

Hello All

I am not sure to understand what exactly is the current status 
http://gcc.gnu.org/ml/gcc/2010-02/msg00270.html of GCC 4.5 with respect 
to plugins. I believe I understand much more its current status w.r.t. 
to other GCC roles (in particular, the major role of generating object 
code from a source one).

Plugins are quite a disruptive feature of 4.5. There is no compatibility 
issues, since it is a new feature. Even more, there are not many 
existing plugins to actually test that feature (it is a chicken & egg 
issue: people will probably start to develop plugins only after 4.5 is 
released).

Plugins are very different of LTO (link time optimization), another 
disruptive feature of 4.5. Because LTO has a natural way of being 
tested: we want that most [not too big] programs which are compiled by 
gcc-4.5 without LTO to be buildable with LTO (i.e. compiled & linked 
with gcc -flto), preferably without loss of performance, and this is an 
easy to test & quite objective criterion. We have no simple criterion 
for plugins.

To be more specific, I feel that current plugin machinery could still be 
improved for the 4.5 time frame. I am more precisely thinking of:

a. some people could want more plugin events to be added inside GCC, 
thus having more plugin hooks.

b. the plugin invocation convention could be improved. In particular, 
one could have (as it is the case of many other major plugin-ehancable 
software, e.g. Mozilla, Qt, Gtk, ...) a specific directory to install 
plugins, and invoke gcc -fplugin=treehydra instead of gcc 
-fplugin=/some/distribution/specific/path/to/treehydra.so ; I did 
propose a patch for that 
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00353.html 
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00476.html but nobody 
really cares :-( Would it be appropriate to issue a ping^5 for it?

c. building plugins (e.g. MELT) requiring gengtype needs both the GCC 
source directory & the GCC build directory (filled by a build which has 
been installed) - this requirement is unusual, distribution-unfriendly, 
and difficult to cope with. I do admit that correcting this kludge is a 
bit of work. http://gcc.gnu.org/ml/gcc/2010-03/msg00129.html - more 
generally, with plugins, several internal tools of GCC (notably 
gengtype, but probably also others) should become installed for plugin 
developers.

In general, is 4.5 frozen to the point that no (even small) plugin 
improvement could be accepted (not even point b)? And could some small 
patch (like my point b) be accepted between hypothetical 4.5.0 & 4.5.1 
releases?

And should I formally make a problem report on bugzilla about each of 
these issues?

The point b is in my view of major importance for plugin users, because 
it is the only way to permit popular plugins to appear and be used the 
same way (thru the same gcc invocation) on various e.g. Linux distributions.

BTW, with Zbigniew Chamski I will give a talk (in French) about GCC 
plugins at Solutions Linux next week in Paris.

Also, MELT has now a script to build it as a plugin, but the gengtype 
requirement that the GCC source & build tree [of the GCC compiler into 
which MELT is plugged in] should be available is a significant 
annoyance, in particular to Debian GCC packagers.

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