[cfe-commits] [PATCH] [clang.py] Refactor how ctypes functions are registered

Gregory Szorc gregory.szorc at gmail.com
Mon Jun 25 10:32:48 PDT 2012


On Mon, Jun 25, 2012 at 12:47 AM, Manuel Klimek <klimek at google.com> wrote:
> +    #lib.clang_annotateTokens.argtype = [TranslationUnit, POINTER(Token),
> +    #                                    c_uint, POINTER(Cursor)]
>
> Is this intentionally commented out?

Yes. The Token class is not defined... yet. I decided to leave these
lines in because I plan to land support for the token API soon. I can
leave them out if you don't like the temporary pollution.

> In general, I like the patch - it's pretty straight forward, so the biggest
> concerns would be high level.
> Perhaps you can loop in whoever originally designed the API for an opinion
> :)

It appears the bindings were originally authored by Andrew Sutton
(checked in by Daniel Dunbar). I've CC'd Andrew (I think - good ole'
gmane email proxies).

Gregory

> On Sat, Jun 23, 2012 at 7:23 AM, Gregory Szorc <gregory.szorc at gmail.com>
> wrote:
>>
>> I've been wanting to do this for a while: this patch refactors how the
>> libclang functions are registered in the Python bindings.
>>
>> Instead of creating a separate symbol for each libclang function, we
>> perform the ctypes magic directly on an instance of the libclang
>> library. Things are defined in a function in the rare case someone
>> wants to have multiple handles to the libclang library.
>>
>> This increases the cohesion between libclang and the Python bindings
>> and IMO makes the Python easier to read since you don't need to
>> maintain a mapping from the Python function name to the libclang
>> function name.
>>
>> Since this deletes symbols from the module, this is technically
>> backwards incompatible. But, I would argue that people should never
>> have been using these symbols directly (they offer little benefit
>> without the classes in the module).
>>
>> This will bit rot the compilation database patch that is pending
>> review on this list. I don't like bit rotting people, so I may hold
>> off landing this until after that patch.
>>
>> There is a high risk of typos in this patch. The nose tests all pass,
>> but our test coverage isn't perfect.
>>
>> Some function definitions from missing features (tokens, resource
>> usage) are commented out because I cherry-picked this patch from my
>> personal branch and these features were implemented in that branch
>> before this patch. I'll simply remove the comments once those
>> corresponding features land (which will be shortly, I hope).
>>
>> Gregory
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>




More information about the cfe-commits mailing list