After a hiatus, I've restarted work on an API for GCC plugins - specifically, a C API (given that my plugin is written in C, I have more interest in that than a C++ API).
BTW, how many other GCC plugins are written in C? It's still a work-in-progress, but can be seen here: http://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/gcc-c-api?h=proposed-plugin-api i.e. within the "proposed-plugin-api" branch of the gcc-python-plugin, within the "gcc-c-api" subdirectory. I've been gradually porting the python plugin to use the proposed API, rather than poking at GCC's insides itself. I've also tried to follow the GNU coding conventions within that directory (the plugin itself follows the Python coding conventions). I haven't done the copyright assignment paperwork yet. There are no explicit test cases yet, though the python plugin's test suite passes, exercising the code indirectly. The API has a build-time dependency on Python (parts of it are autogenerated, and Python is my natural choice for this work). There isn't a runtime dep though. I started thinking about trying to create a patch to merge the API into the GCC source tree, but I'm running into some high-level issues: how is a plugin meant to actually use this API without requiring the use of an in-development version of GCC? Similarly, as a plugin author, I want my plugin to be usable against GCC 4.6 onwards, but GCC's internal APIs are gradually changing. I see a lot of #ifs in my future, and it makes sense to try to isolate the compatibility shims in one place, rather than having every plugin author maintain them. Given that, it's most useful, I think, if the API code can somehow be used independently of GCC: perhaps it's more of a compatibility shim that hides the differences between GCC versions (e.g. C vs C++ name mangling, C++ internals in 4.8 onwards etc) and provides a stable ABI (that way you only have to recompile the API implementation when recompilng GCC: all plugins built against the API should remain compatible - that's the goal, after all). I'm not sure exactly how this is to be structured: external project vs internal to gcc's source tree, but given that this is a non-trivial amount of code and that I want it to support gcc 4.6, perhaps external to the gcc source tree is the way to go. Thoughts? Hope this is helpful Dave
