cindex.py depends on libclang-17.so

[ruffianeo]

Under Debian bullseye it is hard?/impossible? to install package clang-17-dev. As such, cl-bindgen has no chance of working.

I could try to patch cindex.py etc to work with an older libclang.so version or I would have to build clang-17 stuff from sources.

All this could be avoided, if cl-bindgen had a way to just use the clang compiler (with respective compiler options) to access the ast or whatever it needs to generate the bindings.

On my machine, for example:

clang --version
Debian clang version 11.0.1-2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

should work, as afaik, the command liine options for clang to export the ir information exist.

This would make the cl-bindgen tool accessible to a wider range of users, who will run into installation trouble as it is.
Added benefit: If you use the clang executable, you can also write the whole thing in Common Lisp, as you need no dependency on the shared library of clang.
Another added benefit: LLVM is a moving target and using the compilers output might be less susceptible to different llvm/clang versions. => less maintenance.

Hint: clang -Xclang -ast-dump -fsyntax-only your_code.cpp

[sdilts]

I agree that using libclang is a problem, especially with how it is packaged in Python. I didn't know about clang being able to output the AST by itself. That's definitely worth a look.

LLVM is a moving target and using the compilers output might be less susceptible to different llvm/clang versions. => less maintenance.

The Python interface that we are using is supposed to be stable, and mostly is in practice. I have found small differences in the AST between versions, but they have been relatively easy to work around. There is a bug (which I haven't filed yet) that results in duplicate struct definitions, which is caused by forward declarations and started after the clang AST was slightly modified. Other than that, the API itself has been stable. Older versions of libclang should work with this application.

Your best bet is to install a previous version of the libclang python wrappers. The compatible version might be in the Debian repositories, but you should be able to install it from pip as well. After finding a version of libclang compatible with your system, let let me know if there are any compatibility issues with cl-bindgen. You might want to try cl-bindgen version 1.3.0 to see if it works better, as it might not have the same problem with forward declarations that the current version has.

[sdilts]

IIRC, I had to deal with this a while ago, and I think these were the steps I took to get it to work:

1. Install the compatible python bindings to libclang. It looks like pip has version 11.0, so you would do:

   pip install --force-reinstall -v "clang==11.0"
   

   or something like that. See https://stackoverflow.com/questions/5226311/installing-specific-package-version-with-pip
2. Install cl-bindgen. If it tries to do a package upgrade, install cl-bindgen from source, but edit the setup.py file so that that the clang dependency is the version you need. For example, clang=11.

cl-bindgen itself should work with most clang versions. There are differences in behavior between versions, but the API calls themselves should stay consistent. More esoteric C features might not behave as you expect, but the simple stuff should work fine.

If you do get it to run and it generates bad bindings or crashes while they are being generated, let me know. It should be possible to gate features based on what is available in the libclang library.