| 13 Aug 2025 |
 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 |
| sterni (he/him) | which package? | 20:23:45 |
| sterni (he/him) | * which package/version? | 20:23:49 |
| Artem | sterni: liquid-fixpoint. Don't worry: you answered all questions I had so far. Now I need to try what you suggested. | 21:38:54 |
| sterni (he/him) | Artem: ah I think this is a Cabal bug where it doesn't add the tool to PATH and Nix won't do it because it's from the same package, but I'd need to check | 21:40:33 |
| Artem | it sounds like that. I'll grep for the PATH trick. | 21:43:20 |
| 14 Aug 2025 |
| sterni (he/him) | Artem: I guess it is not a bug, actually. build-tool-depends is only available while building, but during test execution it doesn't have to/shouldn't be. | 00:38:18 |
| Artem | Ah, interesting | 00:48:44 |
| Artem | sterni: funny enough, the documentation for BTD seems to bless this usage:
A list of Haskell executables needed to build this component. Executables are provided during the whole duration of the component, so this field can be used for executables needed during test-suite as well.
https://cabal.readthedocs.io/en/3.16/cabal-package-description-file.html#pkg-field-build-tool-depends
| 01:03:13 |
| sterni (he/him) | nevermind then… | 01:06:46 |
| Artem | but there might be a bug in that Cabal the library can't handle BTD correctly. I f memory serves, it was primarily cabal-install feature. There may be a ticket on Cabal's bug tracker... | 01:12:37 |
| Artem | the docs proceed to say that "old-style-builds" (which is what you get with the library, so this includes the Nixpkgs Haskell builder) can't handle external deps in BTD, but internal ones should be OK, which is not what we're seeing | 01:15:38 |
| Artem | the PATH trick looks straightforward in the examples I see but it's not working so far with the old result ("fixpoint not found"). I'm investigating it | 01:29:36 |
| Artem | in particular, that's what I have:
liquid-fixpoint = overrideCabal (drv: {
preCheck = ''
export PATH=dist/build/fixpoint:$PATH
''
+ (drv.preCheck or "");
}) super.liquid-fixpoint;
if I add dist/build/fixpoint/fixpoint --help, I see the help messge from the tool. Yet, the tests fail with /bin/sh: fixpoint: not found. It looks like that PATH doesn't make it all the way through...
| 01:36:26 |
 chreekat | Would using an absolute path help? | 06:27:37 |
| sterni (he/him) | I think it is necessary since the test suite changes directory sometimes: https://github.com/ucsd-progsys/liquid-fixpoint/blob/0171863c853a6076238d2697388f4ad6f2ee43b2/tests/test.hs#L181-L199 | 10:33:42 |
