Newest at the top
2025-05-23 10:57:06 +0200 | pabs3 | (~pabs3@user/pabs3) pabs3 |
2025-05-23 10:56:15 +0200 | pabs3 | (~pabs3@user/pabs3) (Read error: Connection reset by peer) |
2025-05-23 10:54:12 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-05-23 10:53:51 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-05-23 10:53:34 +0200 | tomsmeding | . o O ( cabal install --lib --package-env=some-dir ) |
2025-05-23 10:53:14 +0200 | <dminuoso> | And tear it down afterwards? |
2025-05-23 10:53:06 +0200 | <dminuoso> | sclv: So I guess one solution would be to actually install it into some temporary place? |
2025-05-23 10:52:33 +0200 | <tomsmeding> | it makes sense from an architectural perspective, but as a user, I mean, the first thing you ever do is essentially `cabal run` https://cabal.readthedocs.io/en/stable/getting-started.html |
2025-05-23 10:51:58 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
2025-05-23 10:51:52 +0200 | <sclv> | the issue with run is the binary isn't "installed" anywhere, so the datafiles don't get placed in a location the binary knows to look em up in |
2025-05-23 10:51:17 +0200 | <sclv> | eg give the binary a flag to let it read files from a specified directory |
2025-05-23 10:51:14 +0200 | <tomsmeding> | sclv: thanks for confirming my shakey memory about this :p |
2025-05-23 10:50:53 +0200 | <sclv> | cabal run is about the only circumstance where datafiles don't just immediately work, and it is something that should be fixed. however, its pretty straightforward to hack around that |
2025-05-23 10:50:50 +0200 | <tomsmeding> | I'm not against |
2025-05-23 10:50:26 +0200 | <dminuoso> | Im just suggesting, it would be nice to embed binary data via .cabal rather than TH |
2025-05-23 10:50:20 +0200 | <tomsmeding> | oh I see |
2025-05-23 10:50:10 +0200 | <dminuoso> | Well the programming language for build customization is Setup.hs? |
2025-05-23 10:49:56 +0200 | <haskellbridge> | <sm> I'm sure justine tunney (cosmopolitan c etc) has solutions! |
2025-05-23 10:49:47 +0200 | <tomsmeding> | dminuoso: are you advocating for embedding a little programming language in cabal files so that we can move the customisation there? |
2025-05-23 10:49:41 +0200 | <dminuoso> | Fun. |
2025-05-23 10:49:39 +0200 | <dminuoso> | Or maybe you could generate CPP macros in your Setup.hs which are substitude in the middle of a TH splice |
2025-05-23 10:49:08 +0200 | <dminuoso> | Are you going to propagate cabal flags via CPP to influence TH? |
2025-05-23 10:49:02 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
2025-05-23 10:49:00 +0200 | <dminuoso> | What if the content needs to be customizable? |
2025-05-23 10:49:00 +0200 | <tomsmeding> | there's a philosophical niceness about having data in a separate file on disk from your executable code |
2025-05-23 10:48:49 +0200 | <dminuoso> | Because with file-embed you're tying a build system into the parsing stage of your compiler... |
2025-05-23 10:48:44 +0200 | tomsmeding | doesn't care very much about that difference |
2025-05-23 10:48:36 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
2025-05-23 10:48:28 +0200 | fp | (~Thunderbi@2001:708:20:1406::1370) (Ping timeout: 272 seconds) |
2025-05-23 10:48:25 +0200 | <dminuoso> | I would much prefer text sections in my resulting object files embedded by cabal, rather than as the result of a TH splice. |
2025-05-23 10:47:50 +0200 | <tomsmeding> | but my point is: data files are something rather basic, and if they prohibit standard things that I expect to do with cabal packages, then it's data files that are broken, not `cabal run` |
2025-05-23 10:47:00 +0200 | <tomsmeding> | Accelerate builds some C++ stuff in certain build modes and does so via Setup.hs, but it's fragile |
2025-05-23 10:46:40 +0200 | <tomsmeding> | significant non-haskell dependencies that require build steps _might_ also get a pass to need a custom build system |
2025-05-23 10:46:17 +0200 | <dminuoso> | No it's still bad for me. |
2025-05-23 10:46:09 +0200 | <dminuoso> | It's still headaches, but honestly there just are no sane build systems in this world. |
2025-05-23 10:46:04 +0200 | <tomsmeding> | good for you :) |
2025-05-23 10:45:51 +0200 | <dminuoso> | See, Im building via haskell.nix to get deterministic behavior *and* all the custom nonsense without meddling with Setup.hs :) |
2025-05-23 10:45:43 +0200 | <tomsmeding> | if you get a package from hackage, its data files probably work fine |
2025-05-23 10:45:28 +0200 | <dminuoso> | Oh. |
2025-05-23 10:45:24 +0200 | <tomsmeding> | dminuoso: I'm talking about everything _but_ hackage lol |
2025-05-23 10:45:09 +0200 | <dminuoso> | Besides, the fragility of data-files by itself is perhaps a good indicator why relying on hackage is not the best of ideas. |
2025-05-23 10:44:56 +0200 | <tomsmeding> | I'm not saying that every haskell codebase everywhere must run with `cabal run`, just that the _vast majority_ has not enough claim to specialness to not do so |
2025-05-23 10:44:34 +0200 | <tomsmeding> | (i.e. staged build is sufficient justification for being special :p) |
2025-05-23 10:43:52 +0200 | <tomsmeding> | okay staged ghc build gets a pass too |
2025-05-23 10:43:43 +0200 | <tomsmeding> | dminuoso: ah right, I forgot about the staged build |
2025-05-23 10:43:41 +0200 | <dminuoso> | While yes, you probably could rebuild it all in Setup.hs with enough energy.. |
2025-05-23 10:43:29 +0200 | <tomsmeding> | if you need something that's so complex that even a custom Setup.hs can't handle it, simplify your build process, or justify why you're special |
2025-05-23 10:43:26 +0200 | <dminuoso> | It's simply not trivial. |
2025-05-23 10:43:20 +0200 | <dminuoso> | I dont think age is relevant at all. GHC has a complicated staged build process. |
2025-05-23 10:42:56 +0200 | <tomsmeding> | GHC is a special case that gets allowed its build system madness because it's old and predates cabal |