New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
haskell generic-builder: Use strictDeps always #41420
haskell generic-builder: Use strictDeps always #41420
Conversation
6e0311a
to
b4c2a16
Compare
https://hydra.nixos.org/eval/1460999 is a build of the Haskell package set with this change applied. |
@peti @Ericson2314 Is there anything blocking merge here? |
Yes, the test builds are not complete yet. |
@Ericson2314 It seems like strictDeps does not ameliorate this issue when it is encountered with stack builds (or maybe I'm doing something totally incorrectly). Do you have any idea how to fix the stack build of taffybar? |
@Ericson2314 Actually, it seems that what happens when you enable crossConfig/stictDeps with the stack builder is that all of the haskell-gi generated bindings fail with
I suspect that this is probably because the paths that are passed to the stack build are not properly inherited in the builds for each haskell package, but I have to say that I'm pretty out of my depth with this haskell/stack/nix stuff. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change breaks haskell.packages.ghc843.hspec-discover
. See the "new failing jobs" tab at https://hydra.nixos.org/eval/1460999 for further details.
Weird! This is because GHC cannot find the testsuite from the same package to use a pre-processor. We have tests for this in Cabal https://github.com/haskell/cabal/tree/master/cabal-testsuite/PackageTests/BuildToolDepends; I'd know as I wrote them! |
09e0c1d
to
da046de
Compare
Looks like there's some lingering issues with build tools: |
da046de
to
8f353c8
Compare
Rebased on #42247 which should work to keep things moving. |
8f353c8
to
73ca88d
Compare
https://hydra.nixos.org/eval/1465142. It will probably fail again, but I'd love to be wrong! |
taffybar = super.taffybar.overrideDerivation (drv: { | ||
strictDeps = true; | ||
# https://github.com/hspec/hspec/pull/355 | ||
hspec-discover_2_5_1 = appendPatch super.hspec-discover_2_5_1 (pkgs.fetchpatch { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to be done for hspec-core (and maybe other hspec stuff) as well:
ghc: could not execute: hspec-meta-discover
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK I'll try
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok fixed. didn't realize this was the executable from hspec-meta
, not hspec-discover
.
OK fixed this build, reevaluating. We'll see what fails. |
73ca88d
to
a413506
Compare
Huh. My evaluation hydra evaluation is stuck pending, and just disappeared before that. |
Needed for new ‘strictDeps = true;’ handling. Including- - slim - string-conversions - skeletal-test - catamorphism - unliftio - logging-facade - distributive - doctest - http-types - interpolate - mockery - mime-mail - http2
Weird errors otherwise - seems to need this to know it can skip the bad test.
This is needed for picking up hspec-discover in strictDeps generic-builder.nix.
9abf866
to
4590a37
Compare
This change requires a lot of manual overrides. I think solution @angerman is proposing is less intrusive. Another way is to actually fix the commit that made MAX_ARGS explode: https://github.com/NixOS/nixpkgs/pull/41939/files#diff-360bed088faac7580cee137eeffb39e0R279 |
@domenkozar the big change motivating all the overrides here is we're being explicit for the first time about when we need a binary from another package or just its library. So I think these changes will be very good for multiple outputs (#32629). Also, Cabal 3.0 due at the end of the year will remove the non-new-build stuff, in which case being explicit in the Cabal file will also be required. My guess is Cabal will need to come up with some sort of back-compat story, and we can replace most the overrides with that, probably implemented in Cabal2nix but who knows. |
Oh you mean stuff like this: sol/with-location#1 OK, but why is this needed in order to unbreak ARG_MAX? :) |
Could someone pull in domenkozar@4149778 |
These have changed on master.
53596e2
to
157b597
Compare
Merging for today because of the many breakages on macOS. There are still breakages for now but we should be below 400. strictDeps seems to be the only way to fix this without also breaking cross compilation of haskell. |
@matthewbauer btw adding build tool dependencies should go to |
FYI: it was reverted and I agree with @peti we can autogenerate these: NixOS/cabal2nix#356 |
…h not be non-empty. This commit was originally introduced as part of NixOS#41420 and then reverted with the rest of that PR. However there was no reason to revert his particular commit.
Motivation for this change
This helps avoid the
ARG_MAX
issues we've been having, and is generally a good idea to ensure cross comparability anyways.Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)