plugin directory [ping^3]

[Basile STARYNKEVITCH]

Basile STARYNKEVITCH wrote:
> Hello All
> 
> I am pinging again the patch  
> http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00253.html which is a 
> minuscule improvement (comments & typos) over 
> http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00069.html
> 
> The http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00253.html patch 
> provide the following stuff:
> 

I am attaching a slightly improved patch to trunk rev155790. The only improvement (w.r.t previous submission) is a 
comment saying that the wired-in ".so" suffix should be fixed when non-ELF plugins becomes possible.


One can pass -fplugin=treehydra instead of -fplugin=/some/distribution/dependent/path/to/treehydra.so since there is a 
default location for commonly used plugins. Yes, this defines an additional policy (but GCC already have policies for 
location of crt0.o, or system includes like limits.h files). The main reason for this patch (which does not break 
existing plugin behavior) is to avoid the nightmare situation of commonly available plugins to be invoked in a different 
way on e.g. Debian & Redhat. I believe trying to help users to be able to easily (that is, in the same way) invoke 
common existing plugins is important (and is a minor change, stage 3 or 4 compatible - since no previous release of GCC 
had plugins.).

> The gcc driver is slightly enhanced to pass -iplugindir <plugindirname> 
> to cc1 (etc..) when having -fplugin
> 
> The common.opt has a new (internal) -iplugindir option.
> 
> The gcc-plugin.h has a new plugin_directory_name() public function 
> trivially implemented in plugin.c


While some (e.g. Rafael) apparently believe that defining a tiny policy for common plugins file location might not be 
desirable, I think that permitting a small patch which define a minuscule policy for the new feature of plugins is good. 
Apparently Davek also believes that would help the user (of course, as of today, no commonly used plugins exists, 
because no plugins are distributed, because no GCC release supports plugins yet, except the soon to be released 4.5.0. 
This is a typical chicken & egg situation.). Since I've some positive opinion and some negative one, I am resubmitting 
my patch.

If you feel I should not try hard to help future plugins newbie users and assume that a set of commonly used plugins 
will appear, please tell. But defining such a very minor policy is trivial today (and my patch also permits -fplugin=foo 
in addition of -fplugin=/some/path/to/foo.so thus making GCC command invocation a bit shorter so does not break any 
"existing" plugin.). It would be quite hard when each (e.g. Linux) distribution will implement a slightly incompatible 
one (and such a state would be a nuisance to users; their compilation flags & Makefile will be even more 
distribution-dependent).

BTW, we should perhaps document that (in addition of other few shell variables) the LD_LIBRARY_PATH environment variable 
now impacts the behavior of GCC, since GCC will use dlopen whose behavior is affected by LD_LIBRARY_PATH etc. And 
perhaps without this patch some people might be tempted to set LD_LIBRARY_PATH to be able to pass -fplugin=foo.so 
instead of some much longer program argument (I would recommend against such a practice, and I am proposing this patch 
to make that practice less useful).


I am attaching the patch file (to trunk rev rev155790.) plugindir-rev155790.diff and the gcc/ChangeLog entry.

Ok for trunk (ie future GCC 4.5) if it bootstraps [it did pass stage1 of the bootstrap]? Other comments are welcome.

Regards.

PS. Of course, such a patch would help MELT, by permitting shorter program arguments and by suggesting a policy for 
installation of MELT specific files.

-- 
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} ***
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugindir-rev155790.diff
Type: text/x-patch
Size: 9226 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100110/fee12c3e/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: plugindir-ChangeLog
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20100110/fee12c3e/attachment.ksh>