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: plugin includes for MELT


> I'm trying to understand how other "plugin" related effort deals with
> this.

In an ideal world, you create a plugin API/ABI that is decoupled from
any of the internals of the main program and which has its own headers
and interface.  Plugin authors simply code to that API without involving
any gcc headers.  As a plugin author, this is ideal as you simply grab
this SDK and code your plugin without having to ever touch gcc sources,
and your plugin "just works" with any gcc.

This of course requires a ton more work to create and maintain, since
you have to a) invent a new API that is flexible enough to do everything
that a plugin ever might want to do, and in a way that does not
introduce too many target- or architecture-specific details; b) code
wrappers in gcc that translate the plugin API into the internal
representation; c) maintain those wrappers in the face of changing gcc
internals.  It's been my observation that whenever plugins are
discussed, the majority of gcc maintainers do not want to bear the
maintenance and support burden of this level of decoupling, so it's kind
of a pie in the sky position I think.


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