At least on Debian & Ubuntu, we should check if the packages are available on the system or not before downloading/installing it in bootstrap We could also add it to the list of install. For older Ubuntu & Debian, we could use: https://apt.llvm.org/ (full disclosure, I am the maintainer of what I am mentioning above)

Nathan, what do you think?

My preference is to keep things the way they are: we know the clang from our builds works, and we don't have the same guarantees about some random clang that gets installed from the distro's packages. People who want to work around this can work around this. And we'd like to move to a world where people are downloading all the supplemental code they need from us, anyway.

I agree with Nathan: we've run into too many problems where the Clang isn't "just right." Then people file bugs or show up in #build and we have to spend time debugging problems that could be prevented if people used the same toolchain that CI uses. Let's strive for making the local build experience as similar to automation as possible by default. But we should not prevent people from opting out, of course, because there are many legitimate scenarios calling for that. The correct place for that opt-out for this matter is mozconfigs. That keeps bootstrap streamlined and simple (which is important because the code is hard to test).

Not sure I understand or agree with the rational. It is not different from the other libs or stuff that we install from the Debian or Ubuntu repo: https://dxr.mozilla.org/mozilla-central/source/python/mozboot/mozboot/debian.py?q=debian.py&redirect_type=direct#49 but well, I won't fight/cry on this :)

> we've run into too many problems where the Clang isn't "just right." On Mac and Windows, sure. But on Linux?

(In reply to Sylvestre Ledru [:sylvestre] from comment #4) > Not sure I understand or agree with the rational. > It is not different from the other libs or stuff that we install from the > Debian or Ubuntu repo: > https://dxr.mozilla.org/mozilla-central/source/python/mozboot/mozboot/debian. > py?q=debian.py&redirect_type=direct#49 > but well, I won't fight/cry on this :) libclang, which we're using, has an unstable API. This is pretty different from other libraries that we rely on. I sure don't want to field bug reports about such packages. That being said, folks have put a tremendous amount of work into bindgen to try and make it work with multiple versions of libclang. But I'd still prefer to be conservative here.

Libclang is actually the only stable API in the llvm tool chain. The debian and Ubuntu packages have a list of every symbols and in which version it appeared. Moreover,several versions of Libclang can coexist in parallel and you can force the exact version you need. So, no need to worry about aggressive change of version. I understand that we want to limit the effort but distributions like debian and Ubuntu are going to rely on these packages which are used already a big range of software... Including rust upstream (a least last time I checked, maybe that changed).

Hmm, sorry, I am talking about the c library but this is probably not what we use currently in bindgen!

Seems that rust bindgen uses the C library: https://github.com/KyleMayes/clang-sys/blob/master/src/lib.rs#L1356 (thanks nox) So, this lib API/ABI is stable and monitored though this file (5.0 and 6.0 are the same currently) Example: https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/5.0/debian/libclang1-X.Y.symbols.in