You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 --versionDebian clang version 11.0.1-2Target: x86_64-pc-linux-gnuThread model: posixInstalledDir: /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.
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.
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:
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
The text was updated successfully, but these errors were encountered: