This is the mail archive of the
mailing list for the GCC project.
Re: Proposed plugin API for GCC
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Ludovic Courtès <ludovic dot courtes at inria dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 30 Mar 2012 10:31:56 +0200
- Subject: Re: Proposed plugin API for GCC
- References: <1333054687.31165.65.camel@surprise> <email@example.com>
On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès
> David Malcolm <firstname.lastname@example.org> skribis:
>> How do other plugin authors feel about the API?
> I think this approach would lead to a duplication of each GCC API.
I would call it an abstraction of GCC internals (disclaimer: I did not look
at the proposed API). This abstraction should be easier to learn and
easier to use for 99% of the plugin users. And it should offer a stable
abstraction ABI that makes plugins interoperate with different GCC versions
> The needs of plug-ins cannot be anticipated; artificially restricting
> what plug-ins can do is likely to hinder wider extension of GCC.
Extension of GCC should happen within the GCC codebase. Plugins
are not a replacement of improving GCC!
> As an example, when Emacs was written, probably nobody expected that
> email and IRC clients would be written in it; likewise, probably most of
> the projects at <http://llvm.org/ProjectsWithLLVM/> were not anticipated.
> What about sticking to the current “API” instead, and explicitly marking
> as internal those parts that core developers know are still in flux?
That's not possible. And it is not wanted.
> For instance, I would expect a large subset of <tree.h> and <cgraph.h>
> to be stable (it’s been the case in my experience between 4.5 and 4.7.)
> The rest can be tagged with a special convention (for instance, an ‘i_’
> prefix), to make it clear that it’s only meant for internal consumption.
Sounds like a stupid idea that does not work (yes, plugins that want to
do everything an embedded part of GCC can do are stupid).