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: Proposed plugin API for GCC

On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès
<> wrote:
> Hi,
> David Malcolm <> 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
without recompiling.

> 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 <> 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).


> Thanks,
> Ludo’.

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