Le 3 avr. 2012 à 18:02, David Malcolm a écrit : > On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote: >> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther >> <richard.guent...@gmail.com> wrote: >>> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm <dmalc...@redhat.com> wrote: >>>> I wrote a script and ported my proposed API for GCC plugins from my >>>> CamelCase naming convention to an underscore_based_convention (and >>>> manually fixed up things in a few places also). >>>> >>>> The result compiles and passes the full test suite for the Python >>>> plugin; that said, I'm still breaking the encapsulation in quite a few >>>> places (hey, this is an experimental prototype). >>>> >>>> You can see the latest version of it within the "proposed-plugin-api" >>>> branch of the Python plugin here: >>>> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api >>>> >>>> within the "proposed-plugin-api" subdirectory. >>> >>> Hmm, how do I get it? I did >>> >>> git clone http://git.fedorahosted.org/git/proposed-plugin-api >>> >>> but there is nothing in gcc-python-plugin/. And >>> >>> git checkout proposed-plugin-api >>> >>> says I'm already there ...? >> >> Meanwhile the directory magically appeared (heh ...). > > [The ways of git are something of a mystery to me: 95% of the time it's > the best revision control system I've ever used, but 5% of the time the > most obtuse] > >> Overall it looks good > Thanks for taking a look. > >> - but it seems to leak GCC headers into the >> plugin API (via gcc-plugin.h and input.h inclusion). Thus, it >> lacks separating the plugin API headers from the plugin API implementation >> headers? > That's true. The big information "leak" happens inside > gcc-semiprivate-types.h, which defines the various structs that act like > pointers, each with a decl like this: > > struct gcc_something { > some_private_gcc_pointer_type inner; > }; > > It would be possible to make this more opaque like this: > > struct gcc_something { > struct some_private_gcc_struct *inner; > }; > > given that you then don't need a full definition of that inner struct > visible to users. Though location_t is leaked, and in this approach, > there isn't a way around that, I think.
Well i think we you should define a public type like this : typedef struct some_private_gcc_struct *gcc_something; extern some_type retrieve_some_value(gcc_something); Also, nothing should be noted public or private : all definitions that will appear in a header installed in $(gcc -print-file-name=plugin)/include will be public by definition. Any additional header that would be needed to implement the API should be kept separate (like the actual *.c implementing it) and placed in the gcc/ directory in the trunk (or better something like gcc/plugin-impl/ to start being modular). Any definition defined in those additional headers are private. Thus, you should define two sets of headers files (public and private ones), plus body c files, and import only public header files from public header files. Do you have any plan on starting integrating it to the trunk (or at least on an new branch on the official gcc repository) soon, like suggested by Richard ? I might help setting up the configure/makefile and later writing some wrappers. (although i don't have write permission). Cheers Romain Geissler
