[llvm] [BOLT] Enable standalone build (PR #97130)

[via llvm-commits]

h-vetinari wrote:

> I'm not even sure why is that a thing, and why a builder that is only interested in packaging BOLT wouldn't just build it with:

I help maintain a cross-platform distribution (conda-forge.org), and this would be very helpful to us as well. Here are some reasons why we want to ship llvm as individual (though interdependent) components rather than monolithically:
* Publicly available CI agents cannot build everything in one go (i.e. just building `../llvm` with tests already runs into the 6h timeout imposed by the free azure pipelines agents)
* Reduce footprint of downloads for users and our infrastructure - i.e. only get the pieces that you've specified as dependencies. Especially things like runtime dependencies should be light, because they show up in lots of places.

The first one is a hard constraint that's almost impossible to work around; we don't have a company to pay for CI, so we're stuck with what builds on public CI. The second one is very important at scale (millions of users, billions of downloads) as well.

To get a feeling for what I'm talking about, here's a simplified view of our current split:
* llvmdev (the llvm library, llvm-tools, lit)
* clangdev (clang, clangxx, clang extra tools, libclang; depends on llvmdev)
* compiler-rt (depends on clangdev)
* libcxx (depends on clangdev)
* openmp (depends on llvmdev)
* mlir (depends on llvmdev)
* lld (depends on llvmdev)
* lldb (depends on clangdev)
* flang (depends on llvmdev, compiler-rt, mlir)

Note that these are generally locked to the same version, so we're not asking for arbitrary mixing and matching, just being able to build bolt against an existing `libllvm` (library+headers in some `$PREFIX`).


https://github.com/llvm/llvm-project/pull/97130