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

[Arnaud de Grandmaison]

Gregory,

The compilation database patch is easy to rebase, so feel free not to
hold off. I (would) expect some discussion to happen on the libclang
related part with respect to tooling stuff.

Cheers,
--
Arnaud de Grandmaison

On 06/23/2012 07:23 AM, Gregory Szorc 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


-- 
Arnaud de Grandmaison