exact role[s] of the plugin directory?

exact role[s] of the plugin directory?

[Basile STARYNKEVITCH]

Hello All,

http://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins mention a plugin directory which can be queried with
    gcc-trunk -print-file-name=plugin

Notice that we are calling that plugin, not plugin-header! In my opinion, this is significant.

on my system, after installation of gcc-trunk, I'm getting
/usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin
and currently that directory contains only the include/ file (see PLUGIN_HEADERS in gcc/Makefile.in) needed to compile 
plugins. I call that directory $plugin here.

So my feeling is that today, the plugin directory is exclusively for the header files needed for building plugins.

If this is really the case, we could rename it, and query it with
   gcc-trunk -print-file-name=plugin-headers
and then it should return a directory containing *.h files needed to compile plugins.

However, I see possible other roles of that plugin/ directory, which justify putting an include/ inside, as we are doing 
now!

First, we could define a directory for plugin shared objects. An obvious candidate could be:
    $plugin/libexec
[I mean /usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin/libexec on my system]
and we could decide to put plugin.so files there. I find that attractive, because for commonly used plugins, we could 
install them there, and hack our cc1 (I really mean gcc/plugin.c) so that
   -fplugin=NAME
means really -fplugin=$plugin/libexec/NAME.so ; the major interest of such a feature is for users: they would type a 
much shorter gcc invocation when using system-installed plugins (and we could even have several directories for them, 
for instance one under /usr & another under /usr/local). Of course the -fplugin=/full/path/to/plugin/name.so option 
should still work.

It seems that people have mixed feelings on that idea. I might have perhaps proposed some patch (which did not interest 
anyone, and was buggy) a few months ago. I could try to make a new patch for that. Apparently, the major issue is how to 
get the gcc prefix (ie -B in gcc program argument parlance) from inside a plugin.

Some plugins might need or be happy with some "system" or "configuration" files (this is definitely the case for MELT; 
it needs several files to work.). We could adopt the convention that a plugin foo.so can access $plugin/foo/ and put its 
  files there. We then need a simple (and documented!) way to retrieve the $plugin from inside the source code of a 
plugin.c [maybe it is thru update_path() or some other function]. I would be very happy with a 
plugin_subsystem_directory() function in gcc-plugin.h which would retrieve that $plugin/

These discussions are also related to the *.spec file, which I don't understand well (in particular, how to access its 
information from inside a plugin?).

Of course remains the issue if all those small improvements fits into the current stage3 of trunk.

I would appreciate hearing about other peaple opinions on that matter. I am sure to not be alone interested in that. And 
it is in fact related to packaging in Linux distributions (because it is related to defining & implementing conventions 
relevant in such distributions).

So what do you think the `gcc-trunk -print-file-name=plugin` directory (with backquotes for shell) should be used for?

Cheers

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