I like it! Thank you for doing this.
Specifically, I like how it defaults to strict and users must explicitly
choose to pull out a foot gun.
There's probably potential for hooking up clang_getClangVersion() to
make the compatibility check even stricter. I'm think that the Python
bindings would contain a minimal libclang version. This way, if function
semantics ever change between libclang releases (I know the API is
supposed to be backwards compatible, but you never know), we can detect
that. Don't let this hold up committing this patch though.
On 9/5/12 2:01 AM, Tobias Grosser wrote:
Hi,
I would like to commit the attached patch. Here the intended
commit message:
----------------------
[cindex.py] Make the use of a compatibilty check explicit
At the moment, we implictly check compatibility between the python
bindings and libclang, as the python bindings will fail to load in case
a method we use in libclang is not available.
This patch makes the use of this compatibility check explicit and
introduces a flag to optionally disable the check. This will allow us to
further harden the compatibility check, but it also gives the user the
possibility to disable the compatibility check to evaluate compatibility
with older libclang versions.
I added documentation that makes clear the python bindings are only
tested with the libclang version they have been shipped with.
----------------------
Gregory raised in a recent discussion concerns about silently removing
the compatibility check. I took this as a motivation to make the check
even more explicit, but also introduced an option to disable it if
explicitly demanded. I hope this patch can cater both sides, the users
who want to experiment with multi-version compatibility and the users
who aim for an even stricter compatibility check.
OK to commit?
Tobi
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
