Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cindex.py depends on libclang-17.so #10

Open
ruffianeo opened this issue Dec 29, 2024 · 1 comment
Open

cindex.py depends on libclang-17.so #10

ruffianeo opened this issue Dec 29, 2024 · 1 comment

Comments

@ruffianeo
Copy link

ruffianeo commented Dec 29, 2024

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
Copy link
Owner

sdilts commented Dec 30, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants