[FR] support libclang?

[DanAlbert]

Description

For a while the NDK unintentionally included libclang (since it wasn't intentional, I'm not sure how long it was there). That was removed as part of #2010 to reduce download size. This FR tracks potentially adding that back as something properly supported. Right now that's not something we've got the bandwidth for, but it's worth considering if that ever changes.

The other thread notes that rust workflows need this for bindgen, so that's maybe something that'll force this. OTOH if bindgen needs it, it should probably be shipped with bindgen?

[wqyfavor]

It is so hard to develop Clang plugin with NDK.

NDK not shipping the clang/llvm headers required by plugins. I have to carefully choose exactly the same commit as NDK and build LLVM myself to get those headers. It's a bit troublesome, but tolerable.

After I happily built LLVM with the same commit as NDK and obtained the header files and libclang.dylib required by the plugin, I also happily included and linked it in my plugin and successfully compiled my plugin.

But what frustrates me is that I cannot use Clang that bundled in NDK27 to load my plugin, and I cannot find the libclang I need in NDK27.

Finally, I can only roll back our project to the previous NDK version and repeat the above steps.

[SkewedZeppelin]

fwiw Firefox forks in F-Droid.org were relying[1] on the regular NDK so we didn't have to compile the toolchain every build and Firefox was working just fine for years with the libclang previously available in r26 and older

[1] F-Droid exempts the official NDK and a small handful of other prebuilts, everything else has to be compiled from source

[DanAlbert]

The plan is for libclang to be in r28 (actually supported, on purpose, not just a thing we shipped accidentally like it was before). It'll be absent on Windows for r28 (because that's not something we've ever built, or at least not in recent history), but assuming it's just a matter of flipping the switch, it'll be included for Windows as well for r29. If it's more complicated then Windows support will likely be put on the back burner, depending on how hard it looks to fix.

[pirama-arumuga-nainar]

Windows libclang is now packaged in ToT AOSP clang and will be in r29. But note that libclang-cpp is not available on Windows:

# For MinGW we only enable shared library if LLVM_LINK_LLVM_DYLIB=ON.
# Without that option resulting library is too close to 2^16 DLL exports limit.

Setting LLVM_LINK_LLVM_DYLIB will make all tools link against libLLVM.dll, slowing down the whole build. So the recommendation for users needing Windows libclang-cpp is to build their own toolchain with that CMake option set.