Add zstd support for llvm 16#238266
Conversation
|
Can you detail more what is meant by zstd support and what does it bring concretely? |
@RaitoBezarius This enables features like |
There was a problem hiding this comment.
Thanks for opening this PR! zstd support in LLVM is definitely something we overlooked.
A few comments:
zstdsupport inclangandllddid land in LLVM 16 butzstdwas added to the LLVM support library in LLVM 15: llvm/llvm-project@e939bf6; can you amend this PR to backport this change tollvmPackages_15as well?- edit: will do in a follow up PR
- it'd be nice to have some tests for this (i.e. a passthru test on
clangthat attempts to pass-gz=zstdifenableZstdistrueon the underlyingllvm) but I don't think it's a blocker for this PR - LLVM also has a
LLVM_USE_STATIC_ZSTDoption (added LLVM 16) that does not appear to be autodetected; we may want to pass this explicitly as part of the cmake flags whenstdenv.hostPlatform.isStaticistrue(though I am not sure if this is actually required...)
There was a problem hiding this comment.
I don't see anything in lldb (as of LLVM 16) that uses zstd (and I believe LLVM projects should inherit zstd from propagatedBuildInputs from llvm anyways).
Is there some functionality in lldb that requires zstd as a dep here?
There was a problem hiding this comment.
Is there some functionality in
lldbthat requireszstdas a dep here?
Actually I don't know. I just search where zlib appears, and add zstd. LOL
There was a problem hiding this comment.
Ditto; is this required?
(as an aside I think zlib here is redundant but it's fine; can address that in another PR)
There was a problem hiding this comment.
I remove both zlib and zstd in this file
and it seems that lldb can still be compiled with zlib and zstd support?
cmake found zlib and zstd anyway.
There was a problem hiding this comment.
Can we gate this on an enableZstd input to the package (defaulted to `true)?
There was a problem hiding this comment.
It'd also be nice if we could then propagate it as a passthru (i.e. passthru = { inherit enableZstd; }) so we can gate tests and such in downstream deps (i.e. clang, lld) on it.
There was a problem hiding this comment.
Can we gate this on an
enableZstdinput to the package (defaulted to `true)?
I'm a little confused here.
-
Why we need a feature gate here? It seems that no zstd support brings no benefits from my perspective?
-
I know nothing about tests in nixpkgs. Maybe I need some help about the tests.
There was a problem hiding this comment.
Feature gate is useful to control closure sizes and sometimes when something make a special variant incompatible, e.g. static builds, musl builds, cross compilation, etc.
There was a problem hiding this comment.
If we passthru it, we can recognize whether any LLVM, Clang, LLD at hand is able to do zstd or not and we can decide whether our test harness will attempt to decompress stuff using zstd. Implementing the passthru is the only thing needed here at the moment AFAIK.
|
@rrbutani oops… backporting this to llvm15 seems cause lots of rebuild should we open a separate pr for that? |
Sure! If/when you open that PR, be sure to target |
|
Now that #236420 has reached @SaltyKitkat would you mind adding back in the LLVM 15 changes and retargeting this PR? (instructions for retargeting to |
|
Oops… |
Description of changes
LLVM add zstd support since 16
And maybe we should support that.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)