pybind
Switch to libclang
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==14 where 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_path is 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
/usr/include/unistd.h:226:10: fatal error: 'stddef.h' file not found
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.
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.
Sounds great, but I do worry a bit about https://github.com/sighingnow/libclang/issues/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.