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? How do GCC subsystem maintainers feel? 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 Dave
