This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: default plugin directory?

Hello All,

[Maybe this discussion should happen on gcc@; for the moment I'm leaving it on gcc-patches@]

Diego Novillo wrote:
On Thu, Jun 18, 2009 at 09:30, Basile

Concretely, I am suggesting that some users would pass just
instead of the full path

I'm not sure I like this idea. One can always declare a variable containing the path to the plugins inside a Makefile or build script.

Diego, what is the idea you don't like too much?

1. the idea of passing
instead of -fplugin=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/plugins/

2. the idea of having a single more or less hard-coded directory in which GCC plugins are seeked?

I tend to guess you are a bit empathic to 1 and that you dislike 2, which is my ugly solution to 1.

However, if we are going to do this. How about make it a switch like -B or -L?

$ gcc -fplugin-path=<dir> -fplugin=plugin1 -fplugin=plugin2

This is something I do understand, providing there is a default directory for -fplugin-path.
Or is my idea 1 (shortening the program arguments in the common case) not that good?

If we go towards the -fplugin-path argument idea (which I do like) then we might even make it a real PATH in the Unix sense, i.e. a colon-separated list of directories. Yes I do know that dlopen internally uses LD_LIBRARY_PATH when its argument does not contain a /.

Actually, we could even decide that for plugins, GCC could use an environment variable like GCC_PLUGINS_PATH. To be more precise, I was thinking of something like

first, dlopen the argument passed to -fplugin. If it succeeds, go as usual.

if that argument does not start with a letter or digit or contains the .so string or the / character, fail.

Otherwise, the argument should be a word. Let's suppose it is -fplugin=foo

If -fplugin-path is explicitly passed, it s a colon-separated list of directories. Look for in each of them in turn.

Otherwise (no -fplugin-path) use GCC_PLUGINS_PATH likewise, (it should be a colon-separated list of directories; look for in each of them).

At last, scan a built-in path, which probably should be a single directory, that is $(libexecsubdir)/gcc-plugins.

Ok you probably think I am smoking something terrible; I have lots of nasty habits, but I don't smoke :-)

My scenario is the following:

It is winter 2012. Joe Hacker is so bored that he is compiling the just released Linux kernel on Debian/Unstable. Actually, he did compile two days before; the day before he did aptitude full-upgrade, and Debian Sid gcc bumped from 4.7.2 to 4.7.3 (not a big deal), and Debian Sid gcc-dev bumped likewise -and brought new versions of standard plugins into GCC. Now, Joe Hacker downloaded the kernel patch-, applied it, and rebuilds the kernel.
The kernel community has developped a plugin specific for compiling greener kernels. It is the makegreener plugin. It is very specific to compiling the kernel and has no usefulness outside, but Debian got it inside gcc-dev. The kernel Makefile has
HOSTCFLAGS=-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fplugin=makegreener

I believe the line above is much simpler than
HOSTGCCPLUGINDIR:=(shell gcc -print-file-name=gcc-plugins)
HOSTCFLAGS=-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fplugin=$(HOSTGCCPLUGINDIR)/

This is to illustrate that, I imagine that some few (GPLv3) plugins will appear, that are specific to some big "applications" (IIRC, the kernel community is waiting for some specific GCC plugins suited to warn about simple kernel bugs; such plugins won't change a byte in the generated code, but they will produce some additional warnings.). These plugins of course have to be recompiled (by the distribution guys) at every GCC version bump (even gcc 4.7.2 to 4.7.3 which probably would be a small set of fixes.). These plugins would probably sit at some well defined place. I really can't imagine why the programs compiling with these plugins should change their gcc invocation!

BTW, I am not scared of too much or too big plugins, on the contrary, I am a bit afraid that GCC plugins won't happen enough (and I am not really frightened by proprietary plugins; maintaining them would be nightmare). And the major reason of GCC plugins is probably *application specific* plugins. This kind of code would never get inside the GCC trunk (we definitely won't add some specific warnings relevant only to compile the Linux kernel or Mozilla).


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]