Diego Novillo wrote:
On Wed, Nov 18, 2009 at 09:05, Joern Rennecke <amyl...@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} ***
