| 23 Apr 2026 |
 Alex | I know for certain that build-tools can be made to work, but not specifically build-tool-depends.
Do any of these examples answer your question? | 22:05:46 |
 eldritchcookie | the one package +preprocessing seems to use build-tool-depends how i want to use it | 22:27:42 |
| eldritchcookie | i can't compile and i get a error similar to the one on my own project, so it is something with my ghc/cabal-install version? | 22:36:55 |
| eldritchcookie | which version of cabal was used to compile this project? | 22:37:24 |
| eldritchcookie | wait this is intended to be compiled only via nix? | 22:39:02 |
 m1-s | Not sure if this is the right place but I am looking for feedback for this cabal2nix PR: https://github.com/NixOS/cabal2nix/pull/717 | 22:39:58 |
| 24 Apr 2026 |
 alexfmpe | it is the right place, though I think maintainer(s) of cabal2nix are currently swamped | 10:23:52 |
| alexfmpe | m1-s: I don't understand what you're going for though | 10:24:13 |
| alexfmpe | you can build packages with multiple libraries just fine, here's an example with a ton of them: https://hackage-content.haskell.org/package/raaz-0.3.11/src/raaz.cabal | 10:25:57 |
| alexfmpe | what you can't currently do, is differentiate between multiple components of the same type | 10:26:16 |
| alexfmpe | seems to me your PR differentiates between main-lib and other-libs, not between all libs | 10:26:42 |
| alexfmpe | somewhat related, ICYMI
https://github.com/NixOS/cabal2nix/pull/709
https://github.com/NixOS/cabal2nix/pull/716 | 10:27:09 |
| alexfmpe | well haskell.nix does allow this, but nixpkgs doesn't yet | 10:28:19 |
| alexfmpe | oh I misread, I see your subLibraryDepends is actually a map | 10:29:18 |
| alexfmpe | then I'm confused in a different way, why only do this for libraries? | 10:32:10 |
| m1-s | mhm maybe I misunderstood the current capabilities. I will do some more research. Thanks for your feedback! | 11:23:04 |
| alexfmpe | I mean, the only thing special about library components is that you can have a main library. So I'd expect what you're doing to be applicable to executables/benchmarks/tests | 12:32:12 |
| alexfmpe | I think most of the work is on the nixpkgs side though. We have hundreds of overrides and I'd bet over 100 of them directly rely on current structure, and the rest use dozens of utils that also do | 12:34:29 |
| alexfmpe | So we'll need to make those utils recover current behavior with new structure, then add a migration path for component-granularity override | 12:35:24 |
| alexfmpe | * So we'll need to make those utils recover current behavior with new structure, then add a migration path for component-granularity overrides | 12:35:31 |
| alexfmpe | Maybe the way to go is actually first doing this end to end just for internal libraries which are less common, then gradually rollout to benchmarks, executables, test suites | 12:36:46 |
