Switch to libclang #32
Conversation
|
Bump @drmoose @wjakob @henryiii @Skylion007. Is this project dead? I have stuff to contribute too (and might be willing to maintain the repo) but all these open PRs with no feedback aren't particularly encouraging. |
|
Hello there, and sorry about the delays.I originally started this project but have hence moved all of my energies to the nanobind project. Probably it would be a good idea if somebody else could take over -- can you let me know if either of you would be interested. One quick issue that I see with this PR is that the CI somehow doesn't run. |
A newer package provigind the python libclang bindings is available, called "libclang". Unlike "clang", this package ships the libclang library, removing the dependency from the system's one. This commit adds support for it, using the libclang's builtin library if found and if LIBCLANG_PATH and LLVM_DIR_PATH are not defined. As libclang does not ship the clang standard library headers, some system headers may not be found (like stddef.h), but the documentation generation completes successfully anyways.
|
Sounds great, but I do worry a bit about sighingnow/libclang#82 - the libclang project seems to be a bit behind. |
|
Is there a way we could support either one? Maybe an extra for each (yet another case where default extras would be so nice to have!). I wouldn't want to fully switch due to the issues with libclang being less maintained than clang. |
|
@henryiii FYI: libclang pypi package is maintained by LLVM now. sighingnow/libclang#84 |
5 participants
A newer package provigind the python libclang bindings is available, called "libclang". Unlike "clang", this package ships the libclang library, removing the dependency from the system's one. This dependency is particularly frustrating as it requires not only the presence of libclang on the system, but also a specific version of it, requiring things like
pip3 install clang==14where the version depends on the distro and distro's version.The "libclang" library is identical to the "clang" one, the only difference being a pre-set
index.Config.library_path, set to the package's library.This PR adds support to it, detecting if
index.Config.library_pathis set (and so, if "libclang" is being used) and leaving it as it is unless overridden by the environment variables. With this, pybind11_mkdoc works out-of-the-box.The only issue are the system's headers, not shipped within "libclang" (see sighingnow/libclang#40) which cause some error messages on the stderr like
but the docstrings generation successfully completes anyways.
As a side effect, this fixes pybind11_mkdoc on Arch Linux, as it currently can not find libclang.so (installed under
/usr/lib/, while pybind11_mkdoc searches it under/usr/lib/llvm{version_number}/).Tested only on Linux.