-
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
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 |
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
44b913b
to
2f72704
Compare
Ready for review! #10292 is merged and I've added a release note. |
@mpickering: I'm guessing your comment is addressed? Would you like have a second look? |
This pull request has been removed from the queue for the following reason: The pull request can't be updated. You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you want to requeue this pull request, you need to post a comment with the text: |
@Gabriella439, since you made this PR from your work account, you must rebase it manually and use the |
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]>
2f72704
to
6549f2d
Compare
This pull request has been removed from the queue for the following reason: Pull request #9367 has been dequeued. Pull request automatically merged by a You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you want to requeue this pull request, you need to post a comment with the text: |
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!
Depends-on: #10292