Consider a secondary source of prebuilt artifacts

[dzbarsky]

We ran into an issue of prebuilt clang binaries needing a too-new version of glibc, and that sparked me to build our own clang distribution from source. I made it fully statically linked to avoid glibc issues in the future. See https://github.com/dzbarsky/static-clang/tags

Another reason we did this is because the normal distributions are huge (700MB compressed 5.5GB uncompressed).

I'm planning to continue to tag point releases as they come out, since everything is automated and it's very low effort. @siddharthab Curious to hear what you think of this approach, if you're interested in making this a more-supported option in the toolchain, we can expand the built archive to include the rest of the tools that I've currently stubbed out

[siddharthab]

Interesting! Thanks. If you have the time to do it, you can add this as an additional source of URLs in this repo for auto detection.

Note that users can always explicitly specify their own URLs to bring their own distributions, so we should at the very least add a definition in the tests workspace as an example and run the basic tests in CI. And then maybe mention in the README that people can use your distributions.

As for the stubs you mentioned, it will be confusing if those files are empty. For example, I have used profdata before for use with bazel coverage.

[dzbarsky]

Yep, agreed that I should fix the stubs to prevent confusion from some features not working :)

I think I'll make a use_static_distribution: bool flag on llvm_toolchain (bikeshed names welcome), wire that up to URLs, and then add a test workspace

[siddharthab]

That sounds very good to me.

[peakschris]

@dzbarsky looks cool! Could these include clang-tidy and clang-format, perhaps in separate archives to avoid bloat? And could you support windows?

[peakschris]

This PR is the context to my question: https://github.com/bazel-contrib/toolchains_llvm/pull/342