Newest at the top
| 2025-02-12 22:13:03 +0100 | <euouae> | well, ghc shouldn't be a build system? why is ghc aware of dependencies? |
| 2025-02-12 22:12:58 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-12 22:12:48 +0100 | <euouae> | exactly, that's an issue |
| 2025-02-12 22:12:37 +0100 | <euouae> | yup I see |
| 2025-02-12 22:12:35 +0100 | <merijn> | euouae: This was making me fiddling with my warning flags REALLY fucking slow :p |
| 2025-02-12 22:12:12 +0100 | <merijn> | euouae: Which means: adding/removing a flag via --ghc-options will trigger a recompile of your entire transitive dependency graph (well, unless you already compiled that specific set of flags before) |
| 2025-02-12 22:11:41 +0100 | hattckory | (~hattckory@70.31.30.224) |
| 2025-02-12 22:11:32 +0100 | <merijn> | euouae: The current interpretation of --ghc-options is "transtively applied to all dependencies" |
| 2025-02-12 22:11:21 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca) (Remote host closed the connection) |
| 2025-02-12 22:10:53 +0100 | <merijn> | euouae: If you want the dirty complicated version: There is (or at least at the time of implementation) no way to distinguish between "ghc flags that apply to all transitive dependency of this code" and "ghc flags that apply to thise project *speficially" |
| 2025-02-12 22:10:22 +0100 | <tomsmeding> | "to control ghci without influencing the build", rather |
| 2025-02-12 22:09:51 +0100 | <euouae> | merijn: ah sigh.. it's a messy thing. maybe (NB. use --repl-options on ghc instead) |
| 2025-02-12 22:09:47 +0100 | <merijn> | And only for a deterministic set of flags |
| 2025-02-12 22:09:47 +0100 | <tomsmeding> | merijn: the original was not clearer in that direction :) |
| 2025-02-12 22:09:45 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca) |
| 2025-02-12 22:09:31 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-50-70-31-30-224.dsl.bell.ca) (Remote host closed the connection) |
| 2025-02-12 22:09:23 +0100 | <merijn> | euouae: It is *specifically and only* ghc that is affected |
| 2025-02-12 22:09:15 +0100 | <tomsmeding> | euouae: it's useful for all situations _except_ passing an option to the repl |
| 2025-02-12 22:09:07 +0100 | <merijn> | I mean that formulation is a bit confusing in the sense of "why would it not reliably pass flags?" it sounds like it implies non-determinism |
| 2025-02-12 22:08:57 +0100 | <euouae> | if --PROG-options is not reliable, you might as well deprecate it |
| 2025-02-12 22:08:44 +0100 | <euouae> | it might be nice to mention --repl-options in the docs for --PROG-options? |
| 2025-02-12 22:08:27 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2025-02-12 22:07:48 +0100 | <tomsmeding> | s/game/came/ |
| 2025-02-12 22:07:40 +0100 | <tomsmeding> | (the idea being to turn this from a historical remark of why the flag game to be, to a description of what you can do with it) |
| 2025-02-12 22:07:00 +0100 | <tomsmeding> | (this is the user guide on --repl-options) |
| 2025-02-12 22:06:44 +0100 | <tomsmeding> | merijn: what do you think about this reformulation? https://tomsmeding.com/vang/Qk3nO7 |
| 2025-02-12 22:06:18 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-02-12 22:05:18 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-02-12 22:02:14 +0100 | <merijn> | I'm trying to reverse my logic, but it's split across 2 PRs, annoyingly |
| 2025-02-12 22:02:08 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-02-12 21:59:33 +0100 | <tomsmeding> | it certainly seems to act as if there's no reparsing going on in between, but perhaps that just means that it's properly escaped beforehand |
| 2025-02-12 21:59:04 +0100 | <tomsmeding> | merijn: if I use --ghc-option instead of --ghc-options, the space remains intact |
| 2025-02-12 21:58:33 +0100 | <tomsmeding> | mauke: not if there's escaping/quoting in between |
| 2025-02-12 21:58:25 +0100 | <merijn> | tomsmeding: If you quote it further, presumably |
| 2025-02-12 21:58:08 +0100 | <tomsmeding> | can I not pass an option to GHC that contains a space? |
| 2025-02-12 21:58:06 +0100 | <merijn> | it's complicated |
| 2025-02-12 21:58:03 +0100 | <mauke> | <merijn> euouae: it's a shell process call <-- directly contradicts <merijn> euouae: There is not space splitting |
| 2025-02-12 21:58:03 +0100 | <merijn> | well, a bit |
| 2025-02-12 21:57:59 +0100 | <merijn> | tomsmeding: I mean, not really |
| 2025-02-12 21:57:55 +0100 | <tomsmeding> | why was it designed that way |
| 2025-02-12 21:57:49 +0100 | <tomsmeding> | that's dumb |
| 2025-02-12 21:57:42 +0100 | <tomsmeding> | ah |
| 2025-02-12 21:57:35 +0100 | <merijn> | tomsmeding: Of course not, it's not called as program, it just calls the same logic with a string argument :p |
| 2025-02-12 21:57:34 +0100 | <tomsmeding> | also not if I `cabal clean` first |
| 2025-02-12 21:57:11 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-12 21:57:07 +0100 | <tomsmeding> | I don't see a setup invocation at all |
| 2025-02-12 21:56:53 +0100 | <tomsmeding> | the first call containing "notify-send" is a call to ghc that gets passed "$(notify-send" and "kaas)" as two separate arguments |
| 2025-02-12 21:56:53 +0100 | <merijn> | tomsmeding: Might be just getting reparsed at the Setup step and using execve then |
| 2025-02-12 21:56:30 +0100 | <merijn> | (similar to the two line one cabal init generates) |
| 2025-02-12 21:56:27 +0100 | <tomsmeding> | I just ran `cabal build --ghc-options='$(notify-send kaas)'` in a simple cabal project under a tracer that shows all execve calls |