Fix "bash: Argument list too long" #1937
Conversation
This change avoids duplicates in propagatedBuildInputs it uses `checkUnique` to enforce uniqueness at the top level and `uniqueWithName` fix places where duplicates might arise. For instance: * `packageInputs` in `shell-for.nix` gave rise to duplicates when the shell was for building more than one component (and they shared dependencies). * `libDeps` in `make-config-files.nix` would include duplicates if a `build-dependency` was repeated in a `.cabal` files (Cabal 3.8.1.0 includes two references to `process`). It should also remove duplicate `framework` `lib` and `pkgconfig-depends`. Fixes #1933
There was a problem hiding this comment.
Looks like an improvement! I'm still worried that we can end up with a really big propagatedBuildInputs and I'm not sure what we can do about it (except maybe actually try to use structuredAttrs). Suppose that:
- A and B depend on C
- D depends on A and B
Now I believe that A and B will put C in propagatedBuildInputs, and deduplicate that (no-op). Then when the stdenv creates D's buildInputs, it will jam together the propagatedBuildInputs for a A and B, which will now duplicate C.
So concretely I'd expect to end up with a lot of e.g. instances of containers in there. I guess we could check by inspecting some actual derivations, which I haven't. Maybe Nix is clever enough to get around this somehow.
builder/comp-builder.nix
Outdated
| # Not sure why pkgconfig needs to be propagatedBuildInputs but | ||
| # for gi-gtk-hs it seems to help. | ||
| ++ map pkgs.lib.getDev (builtins.concatLists pkgconfig) | ||
| ++ haskellLib.uniqueWithName (map pkgs.lib.getDev (builtins.concatLists pkgconfig)) | ||
| # These only need to be propagated for library components (otherwise they | ||
| # will be in `buildInputs`) | ||
| ++ lib.optionals (haskellLib.isLibrary componentId) configFiles.libDeps |
There was a problem hiding this comment.
worth a comment that this is already deduplicated
I think it is. We use the The problem in #1933 seems to be that we were putting duplicates in It is concerning that there seems to be a limit to the number of |
# Conflicts: # build.nix
|
This works for me - thanks! |
This change avoids duplicates in propagatedBuildInputs it uses
checkUniqueto enforce uniqueness at the top level anduniqueWithNamefix places where duplicates might arise.For instance:
packageInputsinshell-for.nixgave rise to duplicates when the shell was for building more than one component (and they shared dependencies).libDepsinmake-config-files.nixwould include duplicates if abuild-dependencywas repeated in a.cabalfiles (Cabal 3.8.1.0 includes two references toprocess).It should also remove duplicate
frameworklibandpkgconfig-depends.Fixes #1933