On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm <dmalc...@redhat.com> wrote: > I had a go at writing a possible plugin API for GCC, and porting parts > of my python plugin to it: > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e > > It's very much at the "crude early prototype" stage - all I've wrapped > is part of CFG-handling - but the important thing is that python plugin > *does* actually compile against this, and many of its selftests still > pass (though I'm breaking the self-imposed encapsulation in quite a few > places in order to get it to compile). > > The code is currently jointly owned by me and Red Hat; I'm sure we can > do copyright assignment if/when it comes to that. > > You can see the work-in-progress in the "proposed-plugin-api" branch of > gcc-python-plugin. > > For example, the proposed public header file looks like this: > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/gcc-cfg.h;h=8dbeed0a6c5eb14b0336e89493746887c3bec20a;hb=36a0d6a45473c39db550915f8419a794f2f5653e > > For example, some design notes can be seen at: > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/design.rst;h=31b960ccac2dcf4d007701b5e9c6556e68e0d107;hb=36a0d6a45473c39db550915f8419a794f2f5653e > > How do other plugin authors feel about the API?
Of course I don't like the CamelCasing ;) The important part of the API is that it exposes no data structures and all object references we expose are opaque. You have mostly wrapped in an iterator-style way, I suppose that's fine. That (and the CamelCasing) exposes that using a different language for this API would be desired; use namespaces to avoid CamelCasing and STL style iterators / functors for the rest. If you stay with C rather than using callbacks I would use an explicit iterator representation, similar to how we have that now with gimple_stmt_iterator. Of course that's personal preference, subject to bikeshedding. Would the python plugin have any issue with using C++? > How do GCC subsystem maintainers feel? Well, positive! Thanks for starting. CFG introspection is indeed one of the most important parts, then callgraph and statement introspection. > I initially attempted an underscore_based_naming_convention but quickly > found it difficult to get concise function names, so I switched to a > CamelCaseBased_NamingConvention with an underscore separating a notional > namespace element from a secondary element, which saved plenty of space. > The different naming convention also serves to highlight that this is > *not* part of GCC's internals. > > Hope this is constructive Indeed, and thank you for that. Btw, how ugly is it to make this API grokable by swig? Would that serve the python plugin? Thanks, Richard.
