On 3/13/2013 10:05 PM, Sean Silva wrote:
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.
One thing that REALLY sucks with the current approach is the need to
specify clang -Xclang -load -Xclang <plugin tarball> -Xclang -add-plugin
<plugin name> -Xclang -plugin-<name>-arg -Xclang <blah> ...
With the new approach, the command line is clang -fplugin=<tarball>
-fplugin-arg-<name>-<arg>=<blah>, which is a much shorter command line
and can actually be passed into CFLAGS/CXXFLAGS without driving libtool
bonkers (I detest the need for wrapper scripts just to pass arguments)
and also eliminates warnings whenever people use $(CXX) $(CXXFLAGS) as
the linker. The present crappy command lines really make plugins feel
like second-class citizens to Clang.
The changes in this patch retain almost all of the same functionality as
the original plugin approach (including the ability to do things like
add custom compile passes via the RegisterPass statics) while wrapping
it in a much saner wrapper.
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.
I have often heard that the static analyzer in Clang should be remodeled
as a plugin instead of its current approach, but I'm not exactly sure
what it was meant by that.
Some changes I have personally wanted to be able to do with plugins
include the ability to add custom attribute handlers (using annotate("")
for extra attributes is a very gross hack), as well as be able to
manipulate the pass manager, to make it easier to test custom
optimization or analysis patches--this would even imply, in the long
run, the ability to add custom passes at LTO time. Modelling as plugins
would greatly reduce barriers for other out-of-tree projects that use
LLVM and Clang.
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
--
Joshua Cranmer
News submodule owner
DXR coauthor
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
