* plugins directory?
@ 2009-06-22 11:20 Basile STARYNKEVITCH
2009-06-22 11:35 ` Richard Guenther
0 siblings, 1 reply; 4+ messages in thread
From: Basile STARYNKEVITCH @ 2009-06-22 11:20 UTC (permalink / raw)
To: GCC Mailing List
Hello All,
This is a discussion complementing
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01587.html. So plugins here
means GPLv3 licensed GCC plugins.
First, I believe that progressively, there will be some plugins
dedicated to the compilation of some major specific free software,
mostly for application specific warnings.
For example, it could happen that the Linux kernel community, or KDE/QT
community, or Gnome/GTK community, or Apache community will
progressively develop plugins to help their development. BTW, the
treehydra effort from Mozilla (that is Taras Glek) is illustrative of my
intuition.
I am alone in having this belief (that application specific GCC plugins
would appear, mostly for static analysis or better diagnostic purposes,
not for code generation.)?
If that will happen, most of the plugins will indeed be GCC version
specific (so a gcckde plugin binary -the gcckde-4.7.2.so file- would
indeed be specific to gcc 4.7.2; the same plugin for gcc 4.7.3 would
indeed need a recompilation at least).
I am supposing a user of some -e.g. Linux- distribution which happens to
package commonly used application specific GCC plugins that the user
already installed.. Let's suppose the user is developing a KDE
application. He wants the KDE/QT plugin to check some stuff about his code.
First, I believe that this user does not want to change his makefile
when gcc bumps from 4.7.2 to 4.7.3. As a concrete example, as a
Debian/Sid=Unstable user, I never had to change a Makefile because gcc
bumped from 4.3.2 to 4.3.3. I believe this is practically very important
for plugins to be used (and for application specific plugins to flourish).
So, what is the Makefile that such user would use? It definitely cannot
contain a hardcoded plugin path like e.g.
CXXFLAGS=-fplugin=/usr/lib/gcc/4.7.2/plugins/kdegcc.so -O
At the very least, the hardcoded plugin path should be somehow computed,
e.g.
CXXFLAGS= -fplugin=$(shell pkg-config -gccplugin kde) -O
Alternatively, one could some Debian package would offer a gcc-for-kde
command (probably a shell script) to compile KDE applications.
However, we could suppose that some computation (to find where & which
exact kdegcc.so is loaded) is done by GCC. Concretely, I was thinking of
CXXFLAGS= -fplugin=kdegcc -O
and then we should provide some machinery to find the kdegcc.so plugin
at the appropriate place. BTW, this already happens in GCC for other
stuff: the gcc driver does find and manage the cc1 executable!
I would prefer some discussion to happen, instead of blindly proposing
patches on gcc-patches@ and have them rejected until I find a consensus.
Do you think that
1. We should not care about where system wide plugins are located, and
leave the -fplugin command as it is.
2. We should have a path of GCC plugins, i.e. a sequence of directories
where plugins are searched.
a. should this path be setable only by a -fplugin-path option
b. should this path be also settable thru e.g. an environment variable
like GCC_PLUGINS_PATH
c. what is the default value of this path
Notice that dlopen already uses LD_LIBRARY_PATH, but I feel it is not
entirely appropriate for our purposes (because plugins are not
libraries, even if they share the .so ...).
I think we should reach a consesus quickly: the stage 1 is closing soon,
and such a patch has to happen very soon!
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} ***
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: plugins directory?
2009-06-22 11:20 plugins directory? Basile STARYNKEVITCH
@ 2009-06-22 11:35 ` Richard Guenther
2009-06-23 5:48 ` Basile STARYNKEVITCH
2009-06-24 15:35 ` Diego Novillo
0 siblings, 2 replies; 4+ messages in thread
From: Richard Guenther @ 2009-06-22 11:35 UTC (permalink / raw)
To: Basile STARYNKEVITCH; +Cc: GCC Mailing List
On Mon, Jun 22, 2009 at 1:20 PM, Basile
STARYNKEVITCH<basile@starynkevitch.net> wrote:
> Hello All,
>
> This is a discussion complementing
> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01587.html. So plugins here
> means GPLv3 licensed GCC plugins.
>
> First, I believe that progressively, there will be some plugins dedicated to
> the compilation of some major specific free software, mostly for application
> specific warnings.
> For example, it could happen that the Linux kernel community, or KDE/QT
> community, or Gnome/GTK community, or Apache community will progressively
> develop plugins to help their development. BTW, the treehydra effort from
> Mozilla (that is Taras Glek) is illustrative of my intuition.
>
> I am alone in having this belief (that application specific GCC plugins
> would appear, mostly for static analysis or better diagnostic purposes, not
> for code generation.)?
>
> If that will happen, most of the plugins will indeed be GCC version specific
> (so a gcckde plugin binary -the gcckde-4.7.2.so file- would indeed be
> specific to gcc 4.7.2; the same plugin for gcc 4.7.3 would indeed need a
> recompilation at least).
>
> I am supposing a user of some -e.g. Linux- distribution which happens to
> package commonly used application specific GCC plugins that the user already
> installed.. Let's suppose the user is developing a KDE application. He wants
> the KDE/QT plugin to check some stuff about his code.
>
> First, I believe that this user does not want to change his makefile when
> gcc bumps from 4.7.2 to 4.7.3. As a concrete example, as a
> Debian/Sid=Unstable user, I never had to change a Makefile because gcc
> bumped from 4.3.2 to 4.3.3. I believe this is practically very important for
> plugins to be used (and for application specific plugins to flourish).
>
> So, what is the Makefile that such user would use? It definitely cannot
> contain a hardcoded plugin path like e.g.
> CXXFLAGS=-fplugin=/usr/lib/gcc/4.7.2/plugins/kdegcc.so -O
> At the very least, the hardcoded plugin path should be somehow computed,
> e.g.
> CXXFLAGS= -fplugin=$(shell pkg-config -gccplugin kde) -O
> Alternatively, one could some Debian package would offer a gcc-for-kde
> command (probably a shell script) to compile KDE applications.
>
> However, we could suppose that some computation (to find where & which exact
> kdegcc.so is loaded) is done by GCC. Concretely, I was thinking of
> CXXFLAGS= -fplugin=kdegcc -O
> and then we should provide some machinery to find the kdegcc.so plugin at
> the appropriate place. BTW, this already happens in GCC for other stuff: the
> gcc driver does find and manage the cc1 executable!
>
> I would prefer some discussion to happen, instead of blindly proposing
> patches on gcc-patches@ and have them rejected until I find a consensus.
>
> Do you think that
>
> 1. We should not care about where system wide plugins are located, and leave
> the -fplugin command as it is.
>
> 2. We should have a path of GCC plugins, i.e. a sequence of directories
> where plugins are searched.
> a. should this path be setable only by a -fplugin-path option
> b. should this path be also settable thru e.g. an environment variable like
> GCC_PLUGINS_PATH
> c. what is the default value of this path
>
> Notice that dlopen already uses LD_LIBRARY_PATH, but I feel it is not
> entirely appropriate for our purposes (because plugins are not libraries,
> even if they share the .so ...).
>
> I think we should reach a consesus quickly: the stage 1 is closing soon, and
> such a patch has to happen very soon!
On the contrary. If we put in place such a mechanism we have
to maintain it forever. It is hard to tell what is the correct solution
without distributors facing the problem (there are no existing
plugins that can be packaged or are packaged now).
So, let's wait until the problem happens and we know all of
its aspects and deal with it then.
Richard.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: plugins directory?
2009-06-22 11:35 ` Richard Guenther
@ 2009-06-23 5:48 ` Basile STARYNKEVITCH
2009-06-24 15:35 ` Diego Novillo
1 sibling, 0 replies; 4+ messages in thread
From: Basile STARYNKEVITCH @ 2009-06-23 5:48 UTC (permalink / raw)
To: Richard Guenther; +Cc: GCC Mailing List
Richard Guenther wrote:
> On Mon, Jun 22, 2009 at 1:20 PM, Basile
> STARYNKEVITCH<basile@starynkevitch.net> wrote:
>> I would prefer some discussion to happen, instead of blindly proposing
>> patches on gcc-patches@ and have them rejected until I find a consensus.
>>
>> Do you think that
>>
>> 1. We should not care about where system wide plugins are located, and leave
>> the -fplugin command as it is.
>>
In practice that would mean every plugin use to be wrapped, e.g. by a
CFLAGS=-fplugin=$(shell pkg-config -gccplugins gtkgcc) -O
in a Makefile
>> 2. We should have a path of GCC plugins, i.e. a sequence of directories
>> where plugins are searched.
>> a. should this path be setable only by a -fplugin-path option
>> b. should this path be also settable thru e.g. an environment variable like
>> GCC_PLUGINS_PATH
>> c. what is the default value of this path
>>
>> Notice that dlopen already uses LD_LIBRARY_PATH, but I feel it is not
>> entirely appropriate for our purposes (because plugins are not libraries,
>> even if they share the .so ...).
>>
>> I think we should reach a consensus quickly: the stage 1 is closing soon, and
>> such a patch has to happen very soon!
>>
>
> On the contrary. If we put in place such a mechanism we have
> to maintain it forever. It is hard to tell what is the correct solution
> without distributors facing the problem (there are no existing
> plugins that can be packaged or are packaged now).
I am not sure to agree on that argument. My observation is that most of
the (free, Linux) programs permitting plugins do define some
conventions., which are coded inside the application. (Of course the
convention should be configurable). In some of the applications, the
convention is provided by wrapping the executable in a shell script
(ooffice, firefox). In other applications, the convention is wired in
the binary (so is provided by the source file): java, GTK,QT, ...
It should be noted that we have just to define a convention (and of
course implement it, but the implementation is trivial). And I don't
understand why is maintaining such a convention such a big burden.
If we don't define or propose anything, I would be afraid that either
plugins could be less used, or that various distributions would have
various widely incompatible conventions.
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} ***
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: plugins directory?
2009-06-22 11:35 ` Richard Guenther
2009-06-23 5:48 ` Basile STARYNKEVITCH
@ 2009-06-24 15:35 ` Diego Novillo
1 sibling, 0 replies; 4+ messages in thread
From: Diego Novillo @ 2009-06-24 15:35 UTC (permalink / raw)
To: Richard Guenther; +Cc: Basile STARYNKEVITCH, GCC Mailing List
2009/6/22 Richard Guenther <richard.guenther@gmail.com>:
> On the contrary. If we put in place such a mechanism we have
> to maintain it forever. It is hard to tell what is the correct solution
> without distributors facing the problem (there are no existing
> plugins that can be packaged or are packaged now).
>
> So, let's wait until the problem happens and we know all of
> its aspects and deal with it then.
Agreed, I would rather first evolve the mechanism first. We can
always layer policies on top of the basic mechanism later.
Over-designing everything without usage experience seems premature.
Diego.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-06-24 12:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-22 11:20 plugins directory? Basile STARYNKEVITCH
2009-06-22 11:35 ` Richard Guenther
2009-06-23 5:48 ` Basile STARYNKEVITCH
2009-06-24 15:35 ` Diego Novillo
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).