Originally added in D128465. Used by llvm:Support and lld:ELF.
Enabled by default. Disable with --@llvm_zstd//:llvm_enable_zstd=false.
Differential D143344
[bazel] Port zstd support aaronmondal on Feb 5 2023, 7:49 AM. Authored by
Details
Originally added in D128465. Used by llvm:Support and lld:ELF. Enabled by default. Disable with --@llvm_zstd//:llvm_enable_zstd=false.
Diff Detail
Event TimelineComment Actions Rerun against tests. Previous failure was most likely unrelated to this change, Comment Actions Couple nits, but generally LGTM
Comment Actions
Comment Actions Looks like we didn't make this easy for downstream users to opt out of zstd: they still have to configure it (even if they were to pass the flag). We should add this to llvm_disable_optional_support_deps as well: https://github.com/llvm/llvm-project/blob/b66a6e4b104b245ed448e3dea944fa7e842a96b2/utils/bazel/configure.bzl#L178 Comment Actions Forced 3x speedup across the board xD. Jk this is not good. I think I wrote this after we already had a variant of https://reviews.llvm.org/D143320 running. I'll pick that back up. D143320 was lacking proper support for environment variables. I think fixing that should resolve this issue. Do you want me to revert for now or do you think this is ok until tomorrow? Comment Actions I think tomorrow is fine. For people coming here because they don't have zstd, your options are:
maybe( http_archive, name = "llvm_zstd", build_file = "@llvm-raw//utils/bazel/third_party_build:zstd.BUILD", sha256 = "7c42d56fac126929a6a85dbc73ff1db2411d04f104fae9bdea51305663a83fd0", strip_prefix = "zstd-1.5.2", urls = [ "https://github.com/facebook/zstd/releases/download/v1.5.2/zstd-1.5.2.tar.gz" ], )
cc_library(name = "zstd") and configure it in the WORKSPACE. For instance, use local_repository pointing at a directory containing the BUILD.bazel file and an empty WORKSPACE file, or use new_local_repository referencing that BUILD.bazel file and empty workspace file content: # WORKSPACE local_repository( name = "llvm_zstd", path = "third_party/zstd", ) where that build file with the empty cc_library is at third_party/zstd/BUILD.bazel and there's an empty file at third_party/zstd/WORKSPACE OR # WORKSPACE new_local_repository( name = "llvm_zstd", build_file_content="""cc_library(name="zstd")""", workspace_file_content="", path="<some empty directory. Any empty directory>" ) Where you have to actually have some empty directory to point it, which is annoying. Comment Actions @GMNGeoffrey Unfortunately I think reverting might be better after all. Making this work with WORKSPACES requires wayy too much boilerplate. Same issue for D143320. Adding the http_archive somewhere with a maybe will break bzlmod builds in the future as module extensions intentionally don't support maybe. The current implementation doesn't work well with WORKSPACEs, so that's also not good. Using config_settings seems like a good way in general, but they probably should be in the llvm/BUILD.bazel and not in third_party/zstd.BUILD. After playing around with this for way too long I'm now concluding that having the selects in the llvm BUILD files might be the best way to go. I also think we need to have a clear way of how external deps in general should be handled. I think we *either* need to enforce configuration via .bazelrc *or* configuration via the llvm_configure rule. I'm leaning towards handling it in llvm_configure, but then we'll need to change the attributes of that rule. Maybe we should set a "best effort" goal of replicating the CMake configuration flags in llvm_configure and additional bazel specific flags in .bazelrc. This way we could stay close to the CMake build, let downstream users to declare a specific configuration via llvm_configure and let users that depend on bazel-specific config options (e.g. custom dep overrides) to do this via .bazelrc. Overall there are just too many things problematic with the current state of this patch to roll forward. Comment Actions Hmm I'm against reverting after all. This issue is one of the reasons why bzlmod was created in the first place. See https://bazel.build/external/overview#shortcomings_of_the_workspace_system. Going from there, I think the current workaround is actually the best way forward. It's not pretty, but it seems about as good as it gets with WORKSPACEs. External dependencies *should* be explicitly specified in the workspace file unless we want to adopt a deps.bzl pattern which we'd have to remove again when Bazel 7 deprecates WORKSPACEs (also this pattern has been discouraged for a long time now already). What is currently posted as workaround is probably the best way to handle all external dependencies at the moment and I think this will lead to less friction once we get bzlmod ready. |
Can we use new_git_repository here instead?