<div dir="ltr">On 10 July 2016 at 09:23, Jonathan Müller <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09.07.2016 17:27, Jonathan Coe via cfe-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I've written small extensions to libclang and to the python bindings to<br>
get a code generator I wrote working. If there is a small number of<br>
missing features maybe you could do the same?<br>
</blockquote>
<br></span>
Yes, I should start doing that.<span class=""><br>
<br>
On 09.07.2016 18:13, Reece Dunn via cfe-dev wrote:<br>
><br>
> When I was writing by own libclang python bindings<br>
> (<a href="https://github.com/rhdunn/libclangpy" rel="noreferrer" target="_blank">https://github.com/rhdunn/libclangpy</a>) I had to write custom logic on<br>
> top of the direct bindings to fix bugs in libclang (e.g.<br>
> CursorKind_LinkageSpec is not mapped to the API, so `extern "C" ...`<br>
> does not work) and some support for the newer APIs on older versions of<br>
> libclang.<br>
<br></span>
Did that as well.<span class=""><br>
<br>
<br>
> I also wrote my own tests for the binding to make sure the APIs worked<br>
> consistently on the target and later versions of libclang.<br>
<br></span>
Any documentation on how to do that?<span class=""><br></span></blockquote><div><br></div><div>My approach was to have a custom test driver 'run(version, test)' that called the test function. This would report a skip message if the function raised a missing function or unsupported exception (for Unexposed* cursors) and the libclang version is lower than the one being tested, otherwise it would report a failure. I then created 'test_[APIType][VERSION]' classes, e.g. 'test_TranslationUnit29', as well as tests for specific CursorKind values.<br><br></div><div>This then allowed me to document libclang behaviour differences. For libclang version bugs, I would test the libclang version that had the bug and use the test (with an associated comment) to document the behaviour difference.<br><br></div><div>I have 'match_type' and 'match_cursor' helpers that test those objects and raise unsupported exceptions for unexposed type/cursor kinds.<br></div><div><br></div><div>With the differences documented, I could then work out how to support a consistent behaviour based on the tests and support newer features (e.g. access specifiers) on earlier versions.<br><br></div><div>Thanks,<br></div><div>Reece<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> My verdict was that it was a second class citizen to the unstable C++ API.<br>
<br></span>
Seems like it.<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>