We are currently building LLVM locally for Windows and Linux and uploading that to mrdocs.com because the binaries are too large for GitHub releases. Then the CI scripts get LLVM from mrdocs.com because building LLVM in CI seemed to be unpractical. Uploading these binaries to mrdocs.com is a manual process for practical and permission/security reasons.
This means the cost of changing how LLVM is built or updating LLVM is quite high. Also, #547 now requires us to explore more ways to build LLVM. Hosting the binaries in mrdocs.com also has a cost.
When working on #547, I came across muttleyxd/clang-tools-static-binaries, which by its nature needs to compile LLVM with many different config options for many platforms. It's impressive that it manages to build LLVM in CI and it "only" takes 18m for --target clang-format clang-query clang-tidy clang-apply-replacements, which should also transitively include the ClangLib target we need. So I believe it might be possible for us to do the same by defining the specific targets we need and the compile times would be even slightly lower because we don't need all the clang tools.
So we should try to copy that and simplify our build-install process. Then we could just set the LLVM hash in CI and not depend on updating those custom binaries on the website all the time because that's too time-consuming for the new requirements we have from #547. The LLVM binaries could still be cached to save those 18 minutes, of course. Building LLVM in CI would allow us to implement #547 more easily because all solutions involve building everything (including dependencies) differently.
Also related to #547 is that it involves building all dependencies with new compile options. This means we need to generalize the build/install instructions and move from vcpkg in the general case, even though vcpkg would still work in most cases.
We are currently building LLVM locally for Windows and Linux and uploading that to mrdocs.com because the binaries are too large for GitHub releases. Then the CI scripts get LLVM from mrdocs.com because building LLVM in CI seemed to be unpractical. Uploading these binaries to mrdocs.com is a manual process for practical and permission/security reasons.
This means the cost of changing how LLVM is built or updating LLVM is quite high. Also, #547 now requires us to explore more ways to build LLVM. Hosting the binaries in mrdocs.com also has a cost.
When working on #547, I came across muttleyxd/clang-tools-static-binaries, which by its nature needs to compile LLVM with many different config options for many platforms. It's impressive that it manages to build LLVM in CI and it "only" takes 18m for
--target clang-format clang-query clang-tidy clang-apply-replacements, which should also transitively include the ClangLib target we need. So I believe it might be possible for us to do the same by defining the specific targets we need and the compile times would be even slightly lower because we don't need all the clang tools.So we should try to copy that and simplify our build-install process. Then we could just set the LLVM hash in CI and not depend on updating those custom binaries on the website all the time because that's too time-consuming for the new requirements we have from #547. The LLVM binaries could still be cached to save those 18 minutes, of course. Building LLVM in CI would allow us to implement #547 more easily because all solutions involve building everything (including dependencies) differently.
Also related to #547 is that it involves building all dependencies with new compile options. This means we need to generalize the build/install instructions and move from vcpkg in the general case, even though vcpkg would still work in most cases.