[PATCH] Implement a sane plugin API for clang

Sean Silva silvas at purdue.edu
Wed Mar 13 20:05:45 PDT 2013

While I'm all for the idea of improving the plugin API, I think that a
modest reduction in boilerplate is not sufficiently compelling to foist a
new plugin API on people who already have existing code. The funny thing
about boilerplate is that it's easy to copy-paste, so it doesn't really
impede people from achieving their goals since they can just copy the code
that already works. The primary problem of boilerplate is that it has the
effect of deterring newbies, and that issue can be easily combated with
improved documentation, which avoids breaking every external plugin and
tutorial on plugins.

We really ought to have a preliminary discussion on cfe-dev to map out the
directions we want to take the plugin API, and what *compelling*,
*enabling* changes we can make to it.

Among other things, I think that we should explicitly look at at multiple
plugins "in the wild" and if possible get feedback from as many plugin
authors as possible (preferably, plugin authors that are not also "clang
developers"). Also, we should ask plugin authors what functionality, if
any, they think needs to be added to the plugin API and what were the
biggest difficulties they ran into when developing the plugin.

Also, I think the issue of plugin compatibility (both from a technical and
"policy" standpoint) needs to be rehashed since it has been a while since
it was discussed.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130313/89dbc57f/attachment.html>

More information about the cfe-commits mailing list