* exact role[s] of the plugin directory?
@ 2009-11-24 22:11 Basile STARYNKEVITCH
0 siblings, 0 replies; only message in thread
From: Basile STARYNKEVITCH @ 2009-11-24 22:11 UTC (permalink / raw)
To: GCC Mailing List
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} ***
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2009-11-24 22:11 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-24 22:11 exact role[s] of the plugin directory? Basile STARYNKEVITCH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).