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