-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use response files for ghc
invocations
#9367
base: master
Are you sure you want to change the base?
Use response files for ghc
invocations
#9367
Conversation
Note that this has been tested internally at Mercury not just for We ran into this issue when building our internal Haskell monolith (which has ~7000 Haskell modules), and we verified that this change fixes the problem without breaking anything else. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you run fourmolu
on this (make style
)? That check is failing.
bbe0bd2
to
b689455
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @Gabriella439 for this contribution. 🙇
@Gabriella439 There are still some failures: https://github.com/haskell/cabal/actions/runs/6643530708/job/18050770478?pr=9367#step:16:14024 |
I'm trying to reproduce the problem locally, but when I run |
where | ||
(newIsRTSOption, newResponseFileArgs, newOtherArgs) = | ||
case arg of | ||
"+RTS" -> (True, responseFileArgs, arg : otherArgs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this function already exists in cabal (something similar already exists as filterRtsOpts
), perhaps abstract that and call the same function in both places?
|
||
withResponseFile | ||
verbosity | ||
defaultTempFileOptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please add an option to keep this temporary file, in fact, is it a bug that cabal repl
supports --keep-temp-files
but that option is not honoured here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good direction of travel to me.
I want to block this being merged until there is a way to keep the response file around.
A very common workflow for me is to copy the command line which cabal invokes GHC with so that I can debug GHC issues without going through cabal, it seems this patch would regress that workflow.
9e4dad2
to
b0ef42d
Compare
Currently, `cabal repl` has a `--keep-temp-files` option, and `cabal.project` has a `keep-temp-files` option but it only effects Haddock builds. This patch adds `--keep-temp-files` to `CommonSetupFlags`, making it available to all commands. The expanded `--keep-temp-files` flag is used for the `cabal repl` command and Haddock builds (retaining compatibility with the previous behavior). The flag will also be used for response files; see haskell#9367.
eff868d
to
6d2f9f3
Compare
The requested support for preserving the temp files ended up being much more complicated to implement than I thought it would be, and I just wanted to check with the maintainers to make sure I'm on the right track. I've put the flag in
Am I missing something? Is there a simpler way of doing this? |
e170a59
to
7d04b62
Compare
07570f9
to
25d97f8
Compare
Ready for review, but we should probably merge #10292 first for the |
Added a dependency so Mergify will hold off until it's merged. |
25d97f8
to
b021b34
Compare
b021b34
to
44b913b
Compare
Before this change, `cabal` could fail with the following error message when building very large Haskell packages: ``` ghc: createProcess: posix_spawnp: resource exhausted (Argument list too long) ``` This is because when the number of modules or dependencies grows large enough, then the `ghc` command line can potentially exceed the `ARG_MAX` command line length limit. However, `ghc` supports response files in order to work around these sorts of command line length limitations, so this change enables the use of those response files. Note that this requires taking a special precaution to not pass RTS options to the response file because there's no way that `ghc` can support RTS options via the response file. The reason why is because the Haskell runtime processes these options (not `ghc`), so if you store the RTS options in the response file then `ghc`'s command line parser won't know what to do with them. This means that `ghc` commands can still potentially fail if the RTS options get long enough, but this is less likely to occur in practice since RTS options tend to be significantly smaller than non-RTS options. This also requires skipping the response file if the first argument is `--interactive`. See the corresponding code comment which explains why in more detail. Co-Authored-By: Gabriella Gonzales <[email protected]>
44b913b
to
2f72704
Compare
Ready for review! #10292 is merged and I've added a release note. |
Before this change,
cabal
could fail with the following error message when building very large Haskell packages:This is because when the number of modules or dependencies grows large enough, then the
ghc
command line can potentially exceed theARG_MAX
command line length limit.However,
ghc
supports response files in order to work around these sorts of command line length limitations, so this change enables the use of those response files.Note that this requires taking a special precaution to not pass RTS options to the response file because there's no way that
ghc
can support RTS options via the response file. The reason why is because the Haskell runtime processes these options (notghc
), so if you store the RTS options in the response file thenghc
's command line parser won't know what to do with them.This means that
ghc
commands can still potentially fail if the RTS options get long enough, but this is less likely to occur in practice since RTS options tend to be significantly smaller than non-RTS options.This also requires skipping the response file if the first argument is
--interactive
. See the corresponding code comment which explains why in more detail.Please read Github PR Conventions and then fill in one of these two templates.
Template Α: This PR modifies
cabal
behaviourInclude the following checklist in your PR:
Bonus points for added automated tests!
Template Β: This PR does not modify
cabal
behaviour (documentation, tests, refactoring, etc.)Include the following checklist in your PR:
Depends-on: #10292