[bazel] Rework zlib dependency

[aaronmondal]

Summary

Switches the library to use the zlib-ng implementation since the
original implementation is warning-incompatible with recent versions of clang.

Removes the wrapper logic for zlib in the bazel build and introduces new
logic to handle LLVM_ENABLE_ZLIB.

Removes the BAZEL_LLVM_ZLIB_STRATEGY environment variable and instead
introduces a boolean --@llvm_zlib//:llvm_enable_zlib flag which defaults
to true.

To migrate:

• The previous "external" strategy is the default. May be explicitly enabled with --@llvm_zlib//:llvm_enable_zlib=true. For custom zlib variants you can use the BUILD file at third_party_build/zlib.BUILD as reference and adjust the @llvm_zlib archive in the WORKSPACE directly.
• The previous "disable" strategy may be enabled with --@llvm_zlib//:llvm_enable_zlib=false.
• The previous "system" strategy has been removed since it breaks hermeticity.

Addresses breakages of downstream projects using upstream clang and the
previously "external" zlib strategy (D141553).

[aaronmondal]

• Fix lld:ELF
• Run buildifier on zlib.BUILD

[aaronmondal]

@MaskRay It the patch is ok like this, would you mind commiting on my behalf?

Aaron Siddhartha Mondal <[e-mail]>

[MaskRay]

In D143320#4104455, @aaronmondal wrote:

@MaskRay It the patch is ok like this, would you mind commiting on my behalf?

Aaron Siddhartha Mondal <[e-mail]>

Thanks, I'll do that after giving other reviewers some time to check. (I am unfamiliar with Bazel but I like that this patch reduces complexity!)

[MaskRay]

@aa

utils/bazel/third_party_build/zlib.BUILD

17

Is llvm_zlib_enabled unneeded?

[aaronmondal]

utils/bazel/third_party_build/zlib.BUILD

17

Yes this is not needed at the moment.

[aaronmondal]

Remove redundant llvm_zlib_enabled config setting.

[aaronmondal]

@MaskRay While we're at it, what do you think about changing zlib to zlib-ng? (https://github.com/zlib-ng/zlib-ng) The original zlib still didn't address https://github.com/madler/zlib/issues/633 and I'd rather spend time on writng a buildfile for zlib-ng than to set -Wno-strict-prototypes (or get spammed by a million warnings).

Since this only changes the dep in the Bazel build that should be fine right? Do any other Bazel users have an opinion on this? Note that this wouldn't require codechanges in LLVM. We'd just switch to a different zlib-API-compatible implementation for the Bazel build.

[GMNGeoffrey]

I like that this fixes this to use a proper flag, but support for using the system version was deliberate and static-linking an external archive had interesting licensing implications. Let me dig up the history. Hermeticity is indeed an important consideration, but building with system dependencies is also key functionality. @chandlerc, who added this originally.

[GMNGeoffrey]

Ok it looks like the conversation about licensing implications was in some ephemeral format or something, as I can't find it. And zlib actually has a permissive license. Maybe Chandler will comment, but my preference would be that we keep the ability to depend on the system zlib version

[aaronmondal]

@GMNGeoffrey I originally had a version with a string_flag, but abandoned that because I couldn't solve the following issues:

• Where is the system zlib? Some systems use /lib, some use /usr/lib, some use their 64 bit counterparts. Some use completely different layouts, e.g. /nix/store/<some_config_hash>-zlib-<version>/lib and /nix/store/<some_config_hash>-zlib-<version>-dev/include for zlib on NixOS. How could I ensure that the system is flexible enough for something like that without adding significant amounts of logic?

• How should the difference to the CMake build be handled? The current diff mirrors the behavior of LLVM_ENABLE_ZLIB and the select logic is reasonably friendly to migrate to e.g. the CMake-to-Bazel scripts. The most precise option would be to use two config flags (enable/disable, hermetic/non-hermetic), but that seemed like an awful lot of spaghetti code only to get a single use case working. Since we can't "export" an -lz copt, We'd have to add selects to the LLVM Build file, which seems *very* hacky.

Would patching WORKSPACE in the downstream project be a reasonable approach to get this kind of functionality? The proposed diff makes it very simple to patch the WORKSPACE and zlib.BUILD with local_repository logic.

If you know the systems that use the "system" strategy, you'll also be able to use a module *_overridewith bzlmod in the future. E.g. you could use a custom Bazel registry with a module pointing to specific local paths.

If these migration options and workarounds are not satisfactory I can bring the string_flag back, but please let's only do this if the "system" functionality is actually important enough to justify the additional complexity.

[MaskRay]

In D143320#4106744, @aaronmondal wrote:

@MaskRay While we're at it, what do you think about changing zlib to zlib-ng? (https://github.com/zlib-ng/zlib-ng) The original zlib still didn't address https://github.com/madler/zlib/issues/633 and I'd rather spend time on writng a buildfile for zlib-ng than to set -Wno-strict-prototypes (or get spammed by a million warnings).

Since this only changes the dep in the Bazel build that should be fine right? Do any other Bazel users have an opinion on this? Note that this wouldn't require codechanges in LLVM. We'd just switch to a different zlib-API-compatible implementation for the Bazel build.

Using zlib-ng seems reasonable. I made another comment on https://github.com/madler/zlib/issues/633 just to wish that madler can change his mind...

[GMNGeoffrey]

Aside: this patch appears to be missing a bunch of context in the diff. Could you try reuploading or something?

Good point about a dependent repo being able to override llvm_zlib if they want. Let's make sure that's actually ergonomic, but I think that should be sufficient to support the system case.

Where is the system zlib? Some systems use /lib, some use /usr/lib, some use their 64 bit counterparts. Some use completely different layouts, e.g. /nix/store/<some_config_hash>-zlib-<version>/lib and /nix/store/<some_config_hash>-zlib-<version>-dev/include for zlib on NixOS. How could I ensure that the system is flexible enough for something like that without adding significant amounts of logic?

You'd add -lz as was here previously and let the system handle it. Definitely don't want to reinvent system package search here :-)

Would patching WORKSPACE in the downstream project be a reasonable approach to get this kind of functionality? The proposed diff makes it very simple to patch the WORKSPACE and zlib.BUILD with local_repository logic.

Dependencies don't use the WORKSPACE file from the project they depend on. They can invoke Bazel macros or repo rules that it defines. It would be good to check that this actually makes that ergonomic. https://github.com/llvm/llvm-project/blob/main/utils/bazel/examples/http_archive/WORKSPACE and https://github.com/llvm/llvm-project/blob/main/utils/bazel/examples/submodule/WORKSPACE are examples of how to use the repository. Currently, it's easy to get things up and running with a couple of macros. I think this would break it and zlib would now need to be explicitly configured in the downstream WORKSPACE, repeating all the logic from LLVM's workspace. Can you factor the configuration into a macro so that we can preserve the easy configuration? I propose that we should offer the following macros: llvm_configure, the main repo only as we have it today; for each external dep, llvm_configure_external_<dep_name>; llvm_configure_external_support_deps, pulls in all of the deps as external repos initialized with maybe; llvm_disable_external_support_deps, initializes them all as empty with maybe and makes sure Bazel analysis doesn't get upset because of missing repos. The use of maybe here means that the downstream project can do its own configuration of select deps and then use a catch-all for the rest. If they want to be judicious about taking on dependencies, they can explicitly enable each one they want, but use the macros provided.

utils/bazel/WORKSPACE

38

Somewhat orthogonal to your change, but last week's GitHub sha256 blowup reminded me that http_archive is horrible and we should probably switch to using git_repository

utils/bazel/third_party_build/zlib.BUILD

17–20

Can we make this a positive option? It seems a bit confusing to have it negated like this. I think this works even if true is the default?

config_setting(
  name = "llvm_zlib_enabled",
  flag_values = {":llvm_enable_zlib": "true"},
)

And then the selects would be "if zlib is enabled add this thing, otherwise add nothing" rather than "if zlib is not enabled then don't add anything, otherwise add this thing"

[aaronmondal]

utils/bazel/WORKSPACE

38

It turned out that GitHub actually does guarantee sha stability, but only for release tag links. This *really* screwed all our workflows.

I'd love changing this (and all other http archives), but I think it should be handled in a different commit, since it may break CI environments without git.

utils/bazel/third_party_build/zlib.BUILD

17–20

Yeah I think originally I did it like this so that it's clear that the zlib.BUILD file actually builds zlib source code by default, but looking at it again it indeed seems unnecessarily unintuitive 😆 Will change it.

[GMNGeoffrey]

utils/bazel/WORKSPACE

38

Well I think even there it was just that at some point someone said they would be stable maybe, but obviously didn't communicate that to the team who was actually able to control that :-P Anyway, agreed on it being a separate commit.

[aaronmondal]

In D143320#4108196, @GMNGeoffrey wrote:

You'd add -lz as was here previously and let the system handle it. Definitely don't want to reinvent system package search here :-)

This only works if -L<path_to_lib> is set and may cause inconsistencies in some shells and environments (like Nix), where it becomes unclear whether we are linking -L/usr/lib or -L/veryesotericpath. If that path is unknown or disabled things don't work at all. So far I haven't found a way to "query" for these standard library paths please let me know if there is some some config file or something that I'm not aware of. This is causing me so many headaches.

Regarding the WORKSPACE logic, that sounds good. I'll try to get something like that working but that may take me a while. Tbh I'm not really using WORKSPACES myself and instead using the bzlmod patch series that I tried upstreaming a while ago but I think they got kinda dropped and would probably need some rework at this point. (A working bazel module for a registry is here with sample usage here).

[GMNGeoffrey]

In D143320#4108552, @aaronmondal wrote:

Regarding the WORKSPACE logic, that sounds good. I'll try to get something like that working but that may take me a while. Tbh I'm not really using WORKSPACES myself and instead using the bzlmod patch series that I tried upstreaming a while ago but I think they got kinda dropped and would probably need some rework at this point. (A working bazel module for a registry is here with sample usage here).

Ugh that's my bad. I totally forgot about those :-( I think it enforced naming of the llvm-project repo in a way I found unsavory and I never figured out a solution after getting very lost in what Label appears to do vs what I think the documentation says it does...

[aaronmondal]

In D143320#4108554, @GMNGeoffrey wrote:

Ugh that's my bad. I totally forgot about those :-( I think it enforced naming of the llvm-project repo in a way I found unsavory and I never figured out a solution after getting very lost in what Label appears to do vs what I think the documentation says it does...

Even worse, there is now an additional @@ syntax that i think is supposed to solve issues like that. I *think* it tells bazel to not "resolve" the workspace name or something like that but maybe that's not how it works either 😆

[aaronmondal]

• Rebase
• Make selects positive
• Switch library implementation to zlib-ng

[aaronmondal]

Rename zlib-ng target to zlib

[aaronmondal]

Fix typo

[aaronmondal]

Switch to zip instead of tar.gz, as the latter seems to be broken.

[aaronmondal]

Add strip_include_prefix to allow angled inclusion of zlib.h.

[GMNGeoffrey]

This shows up in "must review" for me, but I think the ball's in your court for preserving the ability to easily set up a dependent project. Please LMK if this (or any of your related patches) are blocked on my review.

utils/bazel/third_party_build/zlib-ng.BUILD

95–97

I don't understand the comment. It looks like it's enabled by default here?

[aaronmondal]

The "migration" necessitated by this patch is pretty much the same as for the zstd commit https://reviews.llvm.org/D143344. The "system" behavior is still possible, but requires the workaround you proposed in https://reviews.llvm.org/D143344. Is that workaround good enough for your needs?

The current bzlmod patches don't allow customization of external dependencies and we need changes like this one to remove dependencies on maybe (which is incompatible with bzlmod by design). It's not exactly "blocking" the patches per se, but it blocks them from being customizable.

I'd also like to move this forward since it would finally get rid of all the zlib deprecation warnings when building with a recent clang and it fixes layering-check issues.

utils/bazel/third_party_build/zlib-ng.BUILD

95–97

Oh yes this is definitely wrong.

[GMNGeoffrey]

In D143320#4348332, @aaronmondal wrote:

Is that workaround good enough for your needs?

It's not ideal from a user perspective that I have to copy-paste code from the workspace. We migrated with the change to zstd though 🤷 The usage of system zlib is something I'm advocating making possible based on recollections of past conversations with Chandler. This doesn't make people accidentally depend on an external version though, so I think it's not terrible from that perspective. I wish the ergonomics were a bit better, but I'm fine with this going in

[aaronmondal]

Improve comment that wasn't wrong but written in a way that was easy misread.

utils/bazel/WORKSPACE

 load("@llvm-raw//utils/bazel:terminfo.bzl", "llvm_terminfo_from_env")
 
 maybe(
     llvm_terminfo_from_env,
     name = "llvm_terminfo",
 )
 
 maybe(
     http_archive,
-    name = "zlib",
-    build_file = "@llvm-raw//utils/bazel/third_party_build:zlib.BUILD",
-    sha256 = "91844808532e5ce316b3c010929493c0244f3d37593afd6de04f71821d5136d9",
-    strip_prefix = "zlib-1.2.12",
+    name = "llvm_zlib",
+    build_file = "@llvm-raw//utils/bazel/third_party_build:zlib-ng.BUILD",
+    sha256 = "e36bb346c00472a1f9ff2a0a4643e590a254be6379da7cddd9daeb9a7f296731",
+    strip_prefix = "zlib-ng-2.0.7",
     urls = [
-        "https://storage.googleapis.com/mirror.tensorflow.org/zlib.net/zlib-1.2.12.tar.gz",
-        "https://zlib.net/zlib-1.2.12.tar.gz",
+        "https://github.com/zlib-ng/zlib-ng/archive/refs/tags/2.0.7.zip",
     ],
 )
 
-load("@llvm-raw//utils/bazel:zlib.bzl", "llvm_zlib_from_env")
-
-maybe(
-    llvm_zlib_from_env,
-    name = "llvm_zlib",
-    external_zlib = "@zlib",
-)
-
 maybe(
     http_archive,
     name = "vulkan_headers",
     build_file = "@llvm-raw//utils/bazel/third_party_build:vulkan_headers.BUILD",
     sha256 = "19f491784ef0bc73caff877d11c96a48b946b5a1c805079d9006e3fbaa5c1895",
     strip_prefix = "Vulkan-Headers-9bd3f561bcee3f01d22912de10bb07ce4e23d378",
     urls = [
         "https://github.com/KhronosGroup/Vulkan-Headers/archive/9bd3f561bcee3f01d22912de10bb07ce4e23d378.tar.gz",

utils/bazel/configure.bzl

 # This file is licensed under the Apache License v2.0 with LLVM Exceptions.
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 """Helper macros to configure the LLVM overlay project."""
 
 load("@bazel_tools//tools/build_defs/repo:utils.bzl", "maybe")
-load(":zlib.bzl", "llvm_zlib_disable", "llvm_zlib_system")
 load(":terminfo.bzl", "llvm_terminfo_disable", "llvm_terminfo_system")
 
 # Directory of overlay files relative to WORKSPACE
 DEFAULT_OVERLAY_PATH = "llvm-project-overlay"
 
 DEFAULT_TARGETS = [
     "AArch64",
     "AMDGPU",
llvm_configure = repository_rule(
     configure = True,
     attrs = {
         "targets": attr.string_list(default = DEFAULT_TARGETS),
     },
 )
 
 def llvm_disable_optional_support_deps():
     maybe(
-        llvm_zlib_disable,
-        name = "llvm_zlib",
-    )
-
-    maybe(
         llvm_terminfo_disable,
         name = "llvm_terminfo",
     )
 
 def llvm_use_system_support_deps():
     maybe(
-        llvm_zlib_system,
-        name = "llvm_zlib",
-    )
-
-    maybe(
         llvm_terminfo_system,
         name = "llvm_terminfo",
     )

utils/bazel/deps_impl/zlib_disable.BUILD

-# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
-# See https://llvm.org/LICENSE.txt for license information.
-# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
-# Empty stub library. This doesn't include zlib and doesn't set the LLVM
-# `#define`s to enable it.
-cc_library(
-    name = "zlib",
-    visibility = ["//visibility:public"],
-)

utils/bazel/deps_impl/zlib_external.BUILD

-# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
-# See https://llvm.org/LICENSE.txt for license information.
-# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
-# Wrapper around an external zlib library to add the relevant LLVM `#define`s.
-cc_library(
-    name = "zlib",
-    defines = ["LLVM_ENABLE_ZLIB=1"],
-    visibility = ["//visibility:public"],
-    deps = ["@external_zlib_repo//:zlib_rule"],
-)

utils/bazel/deps_impl/zlib_system.BUILD

-# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
-# See https://llvm.org/LICENSE.txt for license information.
-# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
-# Wrapper library for the system's zlib. Using this only works if the toolchain
-# already has the relevant header search and library search paths configured.
-# It also sets the relevant LLVM `#define`s to enable zlib.
-cc_library(
-    name = "zlib",
-    defines = ["LLVM_ENABLE_ZLIB=1"],
-    linkopts = ["-lz"],
-    visibility = ["//visibility:public"],
-)

utils/bazel/llvm-project-overlay/lld/BUILD.bazel

deps = [
         "//llvm:Object",
         "//llvm:Option",
         "//llvm:Passes",
         "//llvm:Remarks",
         "//llvm:Support",
         "//llvm:TargetParser",
         "//llvm:TransformUtils",
         "//llvm:config",
+        "@llvm_zlib//:zlib",
         "@llvm_zstd//:zstd",
     ],
 )
 
 gentbl(
     name = "coff_options_inc_gen",
     # See https://github.com/bazelbuild/bazel/issues/13803
     strip_include_prefix = "COFF",

utils/bazel/third_party_build/zlib-ng.BUILD

+# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+load("@bazel_skylib//rules:common_settings.bzl", "bool_flag")
+load("@bazel_skylib//rules:expand_template.bzl", "expand_template")
+
+package(
+    default_visibility = ["//visibility:public"],
+    # BSD/MIT-like license (for zlib)
+    licenses = ["notice"],
+)
+
+bool_flag(
+    name = "llvm_enable_zlib",
+    build_setting_default = True,
+)
+
+config_setting(
+    name = "llvm_zlib_enabled",
+    flag_values = {":llvm_enable_zlib": "true"},
+)
+
+genrule(
+    # The input template is identical to the CMake output.
+    name = "zconf_gen",
+    srcs = ["zconf.h.in"],
+    outs = ["zconf.h"],
+    cmd = "cp $(SRCS) $(OUTS)",
+)
+
+cc_library(
+    name = "zlib",
+    srcs = select({
+        ":llvm_zlib_enabled": [
+            "adler32_p.h",
+            "chunkset_tpl.h",
+            "crc32_p.h",
+            "crc32_tbl.h",
+            "crc32_comb_tbl.h",
+            "deflate.h",
+            "deflate_p.h",
+            "functable.h",
+            "fallback_builtins.h",
+            "inffast.h",
+            "inffixed_tbl.h",
+            "inflate.h",
+            "inflate_p.h",
+            "inftrees.h",
+            "insert_string_tpl.h",
+            "match_tpl.h",
+            "trees.h",
+            "trees_emit.h",
+            "trees_tbl.h",
+            "zbuild.h",
+            "zendian.h",
+            "zutil.h",
+            "adler32.c",
+            "chunkset.c",
+            "compare258.c",
+            "compress.c",
+            "crc32.c",
+            "crc32_comb.c",
+            "deflate.c",
+            "deflate_fast.c",
+            "deflate_medium.c",
+            "deflate_quick.c",
+            "deflate_slow.c",
+            "functable.c",
+            "infback.c",
+            "inffast.c",
+            "inflate.c",
+            "inftrees.c",
+            "insert_string.c",
+            "trees.c",
+            "uncompr.c",
+            "zutil_p.h",
+            "zutil.c",
+        ],
+        "//conditions:default": [],
+    }),
+    hdrs = select({
+        ":llvm_zlib_enabled": [
+            "zlib.h",
+            ":zconf_gen",
+        ],
+        "//conditions:default": [],
+    }),
+    copts = [
+        "-std=c11",
+        "-DZLIB_COMPAT",
+        "-DWITH_GZFILEOP",
+        "-DWITH_OPTIM",
+        "-DWITH_NEW_STRATEGIES",
+        # For local builds you might want to add "-DWITH_NATIVE_INSTRUCTIONS"
+        # here to improve performance. Native instructions aren't enabled in
+        # the default config for reproducibility.
+    ],
+    defines = select({
+        ":llvm_zlib_enabled": [
+            "LLVM_ENABLE_ZLIB=1",
+        ],
+        "//conditions:default": [],
+    }),
+    # Clang includes zlib with angled instead of quoted includes, so we need
+    # strip_include_prefix here.
+    strip_include_prefix = ".",
+    visibility = ["//visibility:public"],
+)

utils/bazel/third_party_build/zlib.BUILD

-# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
-# See https://llvm.org/LICENSE.txt for license information.
-# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
-package(
-    default_visibility = ["//visibility:public"],
-    # BSD/MIT-like license (for zlib)
-    licenses = ["notice"],
-)
-
-cc_library(
-    name = "zlib",
-    srcs = [
-        "adler32.c",
-        "compress.c",
-        "crc32.c",
-        "crc32.h",
-        "deflate.c",
-        "deflate.h",
-        "gzclose.c",
-        "gzguts.h",
-        "gzlib.c",
-        "gzread.c",
-        "gzwrite.c",
-        "infback.c",
-        "inffast.c",
-        "inffast.h",
-        "inffixed.h",
-        "inflate.c",
-        "inflate.h",
-        "inftrees.c",
-        "inftrees.h",
-        "trees.c",
-        "trees.h",
-        "uncompr.c",
-        "zconf.h",
-        "zutil.c",
-        "zutil.h",
-    ],
-    hdrs = ["zlib.h"],
-    copts = [
-        "-Wno-shift-negative-value",
-        "-DZ_HAVE_UNISTD_H",
-    ],
-    includes = ["."],
-)

utils/bazel/zlib.bzl

-# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
-# See https://llvm.org/LICENSE.txt for license information.
-# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
-"""Repository rules to configure the zlib used by LLVM.
-
-Most users should pick one of the explicit rules to configure their use of zlib
-with LLVM:
-- `llvm_zlib_external` will link against an external Bazel zlib repository.
-- `llvm_zlib_system` will link against the system zlib (non-hermetically).
-- 'llvm_zlib_disable` will disable zlib completely.
-
-If you would like to make your build configurable, you can use
-`llvm_zlib_from_env`. By default, this will disable zlib, but will inspect
-the environment variable (most easily set with a `--repo_env` flag to the
-Bazel invocation) `BAZEL_LLVM_ZLIB_STRATEGY`. If it is set to `external`,
-then it will behave the same as `llvm_zlib_external`. If it is set to
-`system` then it will behave the same as `llvm_zlib_system`. Any other
-setting will disable zlib the same as not setting it at all.
-"""
-
-def _llvm_zlib_external_impl(repository_ctx):
-    repository_ctx.template(
-        "BUILD",
-        repository_ctx.attr._external_build_template,
-        substitutions = {
-            "@external_zlib_repo//:zlib_rule": repository_ctx.attr.external_zlib,
-        },
-        executable = False,
-    )
-
-llvm_zlib_external = repository_rule(
-    implementation = _llvm_zlib_external_impl,
-    attrs = {
-        "_external_build_template": attr.label(
-            default = "@llvm-raw//utils/bazel/deps_impl:zlib_external.BUILD",
-            allow_single_file = True,
-        ),
-        "external_zlib": attr.string(
-            doc = "The dependency that should be used for the external zlib library.",
-            mandatory = True,
-        ),
-    },
-)
-
-def _llvm_zlib_system_impl(repository_ctx):
-    repository_ctx.template(
-        "BUILD",
-        repository_ctx.attr._system_build_template,
-        executable = False,
-    )
-
-# While it may seem like this needs to be local, it doesn't actually inspect
-# any local state, it just configures to build against that local state.
-llvm_zlib_system = repository_rule(
-    implementation = _llvm_zlib_system_impl,
-    attrs = {
-        "_system_build_template": attr.label(
-            default = "@llvm-raw//utils/bazel/deps_impl:zlib_system.BUILD",
-            allow_single_file = True,
-        ),
-    },
-)
-
-def _llvm_zlib_disable_impl(repository_ctx):
-    repository_ctx.template(
-        "BUILD",
-        repository_ctx.attr._disable_build_template,
-        executable = False,
-    )
-
-llvm_zlib_disable = repository_rule(
-    implementation = _llvm_zlib_disable_impl,
-    attrs = {
-        "_disable_build_template": attr.label(
-            default = "@llvm-raw//utils/bazel/deps_impl:zlib_disable.BUILD",
-            allow_single_file = True,
-        ),
-    },
-)
-
-def _llvm_zlib_from_env_impl(repository_ctx):
-    zlib_strategy = repository_ctx.os.environ.get("BAZEL_LLVM_ZLIB_STRATEGY")
-    if zlib_strategy == "external":
-        _llvm_zlib_external_impl(repository_ctx)
-    elif zlib_strategy == "system":
-        _llvm_zlib_system_impl(repository_ctx)
-    else:
-        _llvm_zlib_disable_impl(repository_ctx)
-
-llvm_zlib_from_env = repository_rule(
-    implementation = _llvm_zlib_from_env_impl,
-    attrs = {
-        "_disable_build_template": attr.label(
-            default = "@llvm-raw//utils/bazel/deps_impl:zlib_disable.BUILD",
-            allow_single_file = True,
-        ),
-        "_external_build_template": attr.label(
-            default = "@llvm-raw//utils/bazel/deps_impl:zlib_external.BUILD",
-            allow_single_file = True,
-        ),
-        "_system_build_template": attr.label(
-            default = "@llvm-raw//utils/bazel/deps_impl:zlib_system.BUILD",
-            allow_single_file = True,
-        ),
-        "external_zlib": attr.label(
-            doc = "The dependency that should be used for the external zlib library.",
-            mandatory = True,
-        ),
-    },
-    environ = ["BAZEL_LLVM_ZLIB_STRATEGY"],
-)