default plugin directory?

[Rafael Espindola]

> Diego, what is the idea you don't like too much?
>
> 1. the idea of passing
>  -fplugin=treehydra
> instead of -fplugin=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/plugins/treehydra.so
>
> 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.

Not sure about Diego. I am OK with 1 if more people need it, but I don't like 2.

>> $ 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?

Having a default search path that is relative to the install directory
should be fine.

> 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

Please don't use environment variables.

> 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 foo.so 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 foo.so in each of them).
>
> At last, scan a built-in path, which probably should be a single directory,
> that is $(libexecsubdir)/gcc-plugins.

I really think this is too complicated. If doing a search it should be
done is the same way
gcc searches for cc1. I also think that the plugin argument passed to
cc1 should always
contain the full path. The driver is the one that should do the search.


> 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 2.12.9.10 on Debian/Unstable. Actually, he did compile
> 2.12.9.9 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-2.12.9.9-2.12.9.10.diff.bz2, 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)/makegreener.so
>
> 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).
>
> 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} ***
>
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047