| 13 Aug 2025 |
 emily | maybe that dependency is GCC that targets hostPlatform so it can dynamically compile some test code before running it or something. | 18:20:18 |
| emily | like I think the same rule of thumb of "tools used by the build system" applies. | 18:21:06 |
 Alyssa Ross | I guess I'd consider test framework part of the build system | 18:21:58 |
| Alyssa Ross | But really it depends for what purpose it's invoking this tool | 18:22:22 |
| Alyssa Ross | Is it to generate test data? If so, build platform | 18:22:29 |
| emily | it's a Haskell library that provides an interface to an SMT solver | 18:22:35 |
| emily | you write Haskell code and it invokes Z3 at runtime to solve SMT things | 18:22:41 |
| emily | if Z3 was a library, it would be a buildInput | 18:22:48 |
| emily | instead it's something you need to wrap on later | 18:22:55 |
| emily | so it's unambiguously a checkInputs case. it's just that checkInputs sucks to use for executables. | 18:23:04 |
| Alyssa Ross | I see! | 18:23:04 |
| Alyssa Ross | Okay, then this is indeed a check input, and testSystemDepends should be fine. | 18:23:31 |
| emily | arguably we should be patching in the path to Z3 in the library code | 18:23:38 |
| emily | in which case there would be no check inputs needed at all | 18:23:47 |
| emily | (and no wrappers needed for downstream users) | 18:23:52 |
| emily | but that might not be desirable. since you might want to use another backend at runtime | 18:24:02 |
| emily | so having it in the closure of smtlib-backends-process is likely suboptimal | 18:24:17 |
| emily | (does GHC cross even work in Nixpkgs…) | 18:24:39 |
 Artem | if I unbreak certain Haskell package (e.g. by adding jailbreaks and alike in configuration-common.nix), do I remove broken=false; from hackage-packages.nix in the same commit that I want to submit as a PR? | 18:28:55 |
| Artem | ah, I guess I update configuration-hackage2nix/broken.yaml, sorry | 18:33:08 |
| Artem | oh, no, I do :-) | 18:37:24 |
| Artem | Redacted or Malformed Event | 19:03:51 |
| Artem | does Haskell builder understand build-tool-depends in cabal files? I'm seeing a test component that has BTD on an executable in the same package and it can't find it at run time | 19:09:09 |
| Artem | * Does Haskell builder understand build-tool-depends in cabal files? I'm seeing a test component that has BTD on an executable in the same package and it can't find it at run time | 19:21:04 |
| Artem | That's the liquid-fixpoint package, its "test" test suite appears to call to the "fixpoint" executable from the same package but nix-build arrives at:
...
Running phase: checkPhase
Running 2 test suites...
Test suite test: RUNNING...
/bin/sh: fixpoint: not found
| 19:21:05 |
 sterni (he/him) | Artem: you need to add the build directory to PATH before execution since Cabal won't do it for you unfortunately | 19:58:37 |
| sterni (he/him) | there should probably be a shorthand for it, but you can just grep configuration-nix.nix for PATH to see how to do it | 19:58:59 |
| sterni (he/him) | emily: Alyssa Ross: See https://nixos.org/manual/nixpkgs/unstable/#haskell-derivation-deps for input specificication in haskellPackages. Everything is eventually mapped to buildInputs, propagatedBuildInputs and nativeBuildInputs. Using checkInputs and friends is not necessary since that is basically a shorthand for adding lib.optionals doCheck [ … ] to buildInputs/nativeBuildInputs and we have to conditionalize loads on doCheck anyways. | 20:02:03 |
| sterni (he/him) | in the nix build? | 20:04:55 |
| Artem | In reply to @sternenseemann:systemli.org
in the nix build? Yes | 20:23:05 |
