This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed gcc plugin plugin API mk 2 (this time without camel case!)
On Tue, Apr 3, 2012 at 8:15 PM, Romain Geissler
<romain.geissler@gmail.com> wrote:
>
> 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.guenther@gmail.com> wrote:
>>>> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm <dmalcolm@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);
Indeed. I'd go one step further and do
typedef struct gcc_something_s *gcc_something;
and in the implementations only expose struct some_private_gcc_struct
by means of casting the pointer. For the public API gcc_something
is a pointer to an opaque thing, never dereferenced.
> 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.
Right.
Richard.
> 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