llvmPackages/libllvm: do not include static archives when shared is r…

[waldheinz]

Reduces closure size by ~240MiB for LLVM 13, I assume the
others are similar.

[waldheinz]

I was a bit too optimistic when opening this PR because the stripped down version of libllvm is sufficient for mesa, but there are other derivations whicht break. E.g. nix-build -A clang_12 bails out with

CMake Error at //nix/store/z3im54p2im6n9qfv93xfx06sgipyvr8f-llvm-12.0.1-dev/lib/cmake/llvm/LLVMExports.cmake:1358 (message):
  The imported target "LLVMDemangle" references the file

     "/nix/store/8m5pqkjdidzv6hhjr8gansaiq24f7rhl-llvm-12.0.1-lib/lib/libLLVMDemangle.a"

Would it be acceptable to move *.a to the llvm-dev package and patching the CMake file(s) accordingly? I still think that the archives do not belong to the lib output as they are not a runtime dependency.

[waldheinz]

So I just did what I said yesterday and moved the archives to the dev output, which seems to work. I updated the commit message explaning why I think this is the way to go (C++ API is only exposed via the archives for static linking, not the dynlib).

I also manually confirmed that the nixos tests "login" and "sway" succeed, which already exercises those changes quite a bit. Currently my machine is evaluating the "xfce" test. Anything else I should do?

[waldheinz]

I'm not happy with duplicating the exact same change 11 times with this commit, but I fear that's the style the different LLVM versions are handled in nixpkgs. So I think getting rid of the duplication would be out of scope here, if it is desirable at all.

[SuperSandro2000]

I'm not happy with duplicating the exact same change 11 times with this commit, but I fear that's the style the different LLVM versions are handled in nixpkgs. So I think getting rid of the duplication would be out of scope here, if it is desirable at all.

Out of scope but I wouldn't mind if some of this stuff gets deduplicated.

[waldheinz]

I promise I'll come back to this when I have a beefier machine under my desk, the compile times ain't funny. ;-)

[7c6f434c]

This should probably target staging not master.

[waldheinz]

I see, this is a bit exciting. So if there is a consensus that this might be a good idea I'll work on this a bit more to reduce code duplication in nixpkgs and address the same issue in clang (and maybe other derivations under llvmPackages; I'll have a look where it applies).

But before I invest my time on this I'd like to know if this is "the way to go" in general.

I stumbled upon this because llvm.lib is a big dependency of mesa-drivers, so reducing it to a third of it's original size may be of benefit for quite some people. Reducing the size of clang benefits much fewer installations, but it's something.

[7c6f434c]

I think deduplication would need a larger discussion in terms of whether people who do LLVM updates expect significant changes in build procedures between versions in the future.

[sternenseemann]

@waldheinz This change caused llvm-config{,-native} to stop finding the static libraries when looking for them. Can you either adapt llvm-config.patch (I think that should be all that's necessary) or create a revert of this PR?

Edit: I forgot how this changed, patching llvm-config won't really work (or shouldn't) anymore, we need to either make LLVM install into different directories using it's CMake flags and nothing else.

[sternenseemann]

Proposed in #178007.