[plugins-ici-cloning-instrumentation] install-plugin Makefile target

[Basile STARYNKEVITCH]

Diego Novillo wrote:
> On Wed, Nov 18, 2009 at 09:05, Joern Rennecke <amylaar@spamcop.net> wrote:
>> What do people think about making install-plugin not only install
>> headers to build new plugins, but also install all plugins that
>> have been contributed up to the code freeze for the release.
> 
> I agree, but we have no plugins included with the release.  I think it
> would be beneficial to include a tutorial plugin somewhere that shows
> the basics.  I have no opinion on where in the tree.

Diego, are you speaking of the GCC source tree, the GCC build tree, the GCC installation tree?

We could simply adapt a plugin from our testsuite, and install it...

The interesting question is: do we have an installed plugins directory? (We might have already discussed that, I forgot 
the details and the context, probably more than a year ago). I wish we had one:

We might even consider that invoking [sorry to be so selfish and take MELT as a plugin example]
    gcc-4.5 -fplugin=melt ....
doing the same as
    gcc-4.5 -fplugin=$(gcc-trunk --print-file-name=plugin)/libexec/melt.so ....

That is, a plugin only specified with XXX [only letters or digits or underscores, no dots, so no .so extensions, no 
slashes] being searched in some well known directory like 
/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin/libexec/ . If I recall correctly, most other 
pluginable software have their "standard plugin directory".

I would be delighted by having in practice short -fplugin=XXX program argument to GCC. In my understanding, the current 
one is almost always long in practice [because in practice the plugin directory should depend of the GCC version].

The issues are:

   * do we agree that having a well defined directory to contain some installed plugins is desirable?

   * what is that standard plugins directory?

And then, we have to implement & document that.

In the current state of the trunk, it seems that plugins are the only point where environment variables matter, and that 
environment variable is LD_LIBRARY_PATH ... (because dlopen mandates that behavior).

BTW, I think that both MELT & ICI are dlopen-ing their own shared objects (in MELT I call these modules), and that MELT 
(& probably ICI) have some mechanism for some standard paths for these.

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