[llvm] [Bazel] Migrate to Bzlmod (PR #88927)

[Aaron Siddhartha Mondal via llvm-commits]

================
@@ -318,15 +348,17 @@ cc_library(
     deps = [
         ":config",
         ":Demangle",
-        # We unconditionally depend on the custom LLVM zlib wrapper. This will
-        # be an empty library unless zlib is enabled, in which case it will
-        # both provide the necessary dependencies and configuration defines.
-        "@llvm_zlib//:zlib",
-        # We unconditionally depend on the custom LLVM zstd wrapper. This will
-        # be an empty library unless zstd is enabled, in which case it will
-        # both provide the necessary dependencies and configuration defines.
-        "@llvm_zstd//:zstd",
-    ],
----------------
aaronmondal wrote:

Moved to #126729

I did a lot of back-and-forth with the "maybe pattern". The cleaner looking callsites ("depsites" I guess :sweat_smile:) are appealing but I ultimately came to the conclusion that it seems like a bad idea because it abuses implementation details that "just happen" to work in the cc_library case. That is, this isn't a generally applicable pattern that could be used for arbitrary rules because `deps` might not always be implemented transitively.

It also introduces additonal complexity that makes the build graph less efficient (an edge to `maybe_zlib` even if it's unused) and harder to reason about (can no longer easily see which config option influences the dep - need to go to the `maybe` target to check).

However, we can still make this less verbose. #126729 moves the `LLVM_ENABLE_ZLIB` define to the config rather than a `defines` attribute. This not only saves a lot off command-line length but also reduces the overall number of selects. Now the 4 occurances of the zlib dep in the overlay add just 3 additional selects over the maybe approach (as opposed to the previous 6) and just 1 additional select in the zstd case (as opposed to the previous 2).

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