On Fri, Sep 7, 2012 at 6:31 PM, David Malcolm <dmalc...@redhat.com> wrote: > 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?
Micha was also working on the proposed introspection API, I blame him for not posting anything about this despite it's being "ready" since a few months... Richard. > Hope this is helpful > Dave >
