Skip to content

Commit

Permalink
Do not build amazonka-ec2 in parallel (and skip haddock).
Browse files Browse the repository at this point in the history
  • Loading branch information
@alaendle
alaendle committed Aug 1, 2023
1 parent 86a1e08 commit ac60194
Showing 1 changed file with 2 additions and 0 deletions.
2 changes: 2 additions & 0 deletions build-constraints.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9510,6 +9510,7 @@ expected-haddock-failures:

# For packages with haddock issues
skipped-haddocks:
- amazonka-ec2 # Large memory consumption - https://github.com/brendanhay/amazonka/issues/549
- modular # Module uses compiler plugins https://github.com/haskell/haddock/issues/900
# end of skipped-haddocks

Expand Down Expand Up @@ -9882,6 +9883,7 @@ no-revisions:
# Do not build these packages in parallel with others. Useful for high memory
# usage.
non-parallel-builds:
- amazonka-ec2 # Large memory consumption - https://github.com/brendanhay/amazonka/issues/549
- pandoc
- gogol-dfareporting
- gogol-compute
Expand Down

3 comments on commit ac60194

@ysangkok
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The linked issue is closed, if this is still actually an issue it should be reopened.

@alaendle
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I don't see this as a "real" issue - the compilation takes around 6 GB RAM (which could be considered to be much or not); and there are already follow-up issues like - brendanhay/amazonka#717 - in place - so no need to just add another issue (also the original issue is quite old and wasn't really solved). So to keep it short, I think it is good enough to avoid parallel building and skip haddock (which also uses lot of memory) for this module - as it is for sure an improvement to the situation before where the package was just disabled. Also the related and still open GHC issue tells that originally the compilation needs more than 10 GB (so things improved). So for me this commit had more an optimization character (to save memory and maybe also time) and the mentioning of the closes issue was intended to act as a reference. But you are right, this is misunderstandable - so I will replace the comment. If you think it is worth to analyze the memory issue in more detail - the consumption should be easy to reproduce locally.

@ysangkok
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right, thanks for the reply! Happy to hear that it really did improve.

Please sign in to comment.