[cfe-dev] issue with libclang and Python bindings

[Trevor Laughlin via cfe-dev]

Hello,

 

I'm using libclang and its Python bindings to build a binding generator to a
large C++ library using pybind11. All is going well but I am experiencing a
strange issue and I'm hoping someone on this list has an idea.
Unfortunately, I'm not able to reproduce the issue on a small scale so I'll
just describe it as best I can and if anyone has any thoughts please share.

 

I have a single include file ("all_includes.h") that includes all the
headers of the C++ library. This file is parsed by libclang and I use the
results to write pybind11 code via the libclang Python bindings. I don't get
any translation errors or warnings. In some cases, certain types (usually
parameter declarations) get resolved to "int" instead of the actual type
like "std::list<TypeA>".

 

If my "all_inlcudes.h" has only the header file where the issue occurs, the
types are resolved correctly. It's only when I include all my headers (or a
large number of them) does this strange behavior start to appear. I can't
figure out a root reason or pattern for it happening, the only thing I've
noticed is it seems to happen with things in a namespace liked "std::list<>"
or "TypeA::value".

 

One other thing, the C++ library makes heavy use of class templates. In
libclang, these class declarations have no children (i.e., constructors,
methods, etc.). In order to generate the binding code I have to retrieve the
cursor to the class template, write its code then replace the template
parameters with a string replace method. Is there a reason these class
declarations from class templates don't resolve the children of the class
template with the template parameters already in place? It would make the
binding generation process much easier and robust.

 

For either of these issues, my next step is to rewrite my binding generation
tool in C++ and use the clang libraries like LibTooling. They seem to
provide more functionality anyway, but the Python version is so close I'd
thought it'd be worth asking before I go down that path.

 

Thanks,

Trevor

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171105/40966694/attachment.html>