| 13 Aug 2025 |
 Artem | I'm trying to unbrake some packages from liquidhaskell ecosystem. One package's test suite assumes Z3 is available in the PATH. What's a better way to fix it: dontCheck or add z3 as a dependency somewhere (where?). | 16:27:58 |
 emily | probably nativeCheckInputs | 16:28:52 |
| Artem | @emily this looks plausible except I don't see it ever be used inside haskell-modules. I see a bunch of those in other *-modules, but they have a different setup, so I'm not sure where to put these nativeCheckInputs for a haskell package | 16:37:37 |
 Alyssa Ross | Where would you put extra buildInputs or nativeBuildInputs? | 16:41:27 |
| Alyssa Ross | Those must be used somewhere | 16:41:36 |
| Artem | I'm not really seeing those in haskell-modules either | 16:48:14 |
| Alyssa Ross | I do, in configuration-nix.nix | 16:48:55 |
| Alyssa Ross | oh, addBuildDepend sounds relevant | 16:49:10 |
| Alyssa Ross | It doesn't look like there's an equivalent for nativeCheckInputs, so add one? | 16:50:52 |
 maralorn | I love how this extra abstraction layer in the haskell builder trips up proficient nixpkgs users … otoh I am always confused how those fields are called in the default builder. 😄 | 16:50:52 |
| maralorn | There is testSystemdDepends. | 16:52:21 |
| Alyssa Ross | Is that nativeCheckInputs though? | 16:52:52 |
| maralorn | testPkgconfigDepends ? [ ],
testDepends ? [ ],
testHaskellDepends ? [ ],
testSystemDepends ? [ ],
testFrameworkDepends ? [ ],
| 16:53:01 |
| Artem |
There is testSystemdDepends.
with testSystemDepends it seems like it, thanks
| 16:53:52 |
| Artem | *
There is testSystemdDepends.
with testSystemDepends it seems like it, thanks
| 16:53:59 |
| maralorn | no. It uses buildInputs. | 16:54:40 |
| Alyssa Ross | Then that's not the right thing! | 17:14:49 |
| Artem | smtlib-backends-process = overrideCabal (drv: {
testSystemDepends = (drv.testSystemDepends or [ ]) ++ [ pkgs.z3 ];
}) super.smtlib-backends-process;
works. So, should I try to use something closer to nativeCheckInputs instead?
| 17:21:22 |
| maralorn | Well it was clearly the intent by the author of the Haskell builder to use it like this. He might have been wrong about it. Can you come up with a bug which can be triggered by this confusion? | 17:55:21 |
| maralorn | Well, I think your solution is fine and the rest might need fixing in the Haskell builder. | 17:55:55 |
| Alyssa Ross | In reply to @maralorn:maralorn.de
Well it was clearly the intent by the author of the Haskell builder to use it like this. He might have been wrong about it. Can you come up with a bug which can be triggered by this confusion? Wrong package will be used when cross compiling I think | 17:58:08 |
| maralorn | Ah, well. How can you even test when cross compiling?^^ | 18:04:53 |
| Alyssa Ross | Imagine cross compiling from glibc to musl, or x86_64 to i686 | 18:05:38 |
| maralorn | I mean I also find the code around that very confusing because it has "otherBuildInputsSystem" and "otherBuildInputs" which are both used and there is a TODO there. | 18:05:48 |
| Alyssa Ross | Cross compiling doesn't necessarily mean you can't execute | 18:05:50 |
| maralorn | I see. Fair. | 18:06:10 |
| Alyssa Ross | Which is why we have a predicate in Nixpkgs called canExecute, which stdenv uses to decide whether to have checkPhase and reference checkInputs and nativeBuildInputs | 18:06:14 |
| emily | (btw I have solved the LLVM 12 problem. still a WIP draft locally. but my experiment was a success) | 18:06:49 |
| emily | (it is a joyous occasion) | 18:07:05 |
| Alyssa Ross | * Which is why we have a predicate in Nixpkgs called canExecute, which stdenv uses to decide whether to have checkPhase and reference checkInputs and nativeCheckInputs | 18:07:40 |
