plugins directory?

[Basile STARYNKEVITCH <basile@starynkevitch.net>]

Hello All,

This is a discussion complementing 
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01587.html. So plugins here 
means GPLv3 licensed GCC plugins.

First, I believe that progressively, there will be some plugins 
dedicated to the compilation of some major specific free software, 
mostly for application specific warnings.
For example, it could happen that the Linux kernel community, or KDE/QT 
community, or Gnome/GTK community, or Apache community will 
progressively develop plugins to help their development. BTW, the 
treehydra effort from Mozilla (that is Taras Glek) is illustrative of my 
intuition.

I am alone in having this belief (that application specific GCC plugins 
would appear, mostly for static analysis or better diagnostic purposes, 
not for code generation.)?

If that will happen, most of the plugins will indeed be GCC version 
specific (so a gcckde plugin binary -the gcckde-4.7.2.so file- would 
indeed be specific to gcc 4.7.2; the same plugin for gcc 4.7.3 would 
indeed need a recompilation at least).

I am supposing a user of some -e.g. Linux- distribution which happens to 
package commonly used application specific GCC plugins that the user 
already installed.. Let's suppose the user is developing a KDE 
application. He wants the KDE/QT plugin to check some stuff about his code.

First, I believe that this user does not want to change his makefile 
when gcc bumps from 4.7.2 to 4.7.3. As a concrete example, as a 
Debian/Sid=Unstable user, I never had to change a Makefile because gcc 
bumped from 4.3.2 to 4.3.3. I believe this is practically very important 
for plugins to be used (and for application specific plugins to flourish).

So, what is the Makefile that such user would use? It definitely cannot 
contain a hardcoded plugin path like e.g.
CXXFLAGS=-fplugin=/usr/lib/gcc/4.7.2/plugins/kdegcc.so -O
At the very least, the hardcoded plugin path should be somehow computed, 
e.g.
CXXFLAGS= -fplugin=$(shell pkg-config -gccplugin kde) -O
Alternatively, one could some Debian package would offer a gcc-for-kde 
command (probably a shell script) to compile KDE applications.

However, we could suppose that some computation (to find where & which 
exact kdegcc.so is loaded) is done by GCC. Concretely, I was thinking of
CXXFLAGS= -fplugin=kdegcc -O
and then we should provide some machinery to find the kdegcc.so plugin 
at the appropriate place. BTW, this already happens in GCC for other 
stuff: the gcc driver does find and manage the cc1 executable!

I would prefer some discussion to happen, instead of blindly proposing 
patches on gcc-patches@ and have them rejected until I find a consensus.

Do you think that

1. We should not care about where system wide plugins are located, and 
leave the -fplugin command as it is.

2. We should have a path of GCC plugins, i.e. a sequence of directories 
where plugins are searched.
  a. should this path be setable only by a -fplugin-path option
  b. should this path be also settable thru e.g. an environment variable 
like GCC_PLUGINS_PATH
  c. what is the default value of this path

Notice that dlopen already uses LD_LIBRARY_PATH, but I feel it is not 
entirely appropriate for our purposes (because plugins are not 
libraries, even if they share the .so ...).

I think we should reach a consesus quickly: the stage 1 is closing soon, 
and such a patch has to happen very soon!

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