Skip to content

[chore] adjust readme to save users some hours #27

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.

Sign up for GitHub

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

Open
MangoIV wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[chore] adjust readme to save users some hours #27

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,9 @@ An impact assessment is due when

The procedure is as follows:

1. Rebase changes, mandated by your proposal, atop of `ghc-9.10` branch.
1. Rebase changes, mandated by your proposal, atop of `ghc-9.10.2` tag. Mind: the branch `ghc-9.10` is not okay since different minor versions
Copy link
Collaborator

@Bodigrim Bodigrim Nov 10, 2025

Choose a reason for hiding this comment

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

Could we express it in a way, which would require less updates in the future, when Stackage moves to newer versions of GHC?

Copy link
Author

@MangoIV MangoIV Nov 11, 2025

Choose a reason for hiding this comment

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

I'm not sure what the update policy is. Since this mentions 9.10 anyway, I thought it's fine if this is just changed whenever the stackage is (rarely) updated.

Copy link
Author

@MangoIV MangoIV Nov 11, 2025

Choose a reason for hiding this comment

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

Do you have any suggestions, perhaps? I'm not a maintainer so I don't wanna suggest anything that is hard to maintain.

Copy link
Collaborator

@Bodigrim Bodigrim Nov 12, 2025

Choose a reason for hiding this comment

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

First of all, while stackageSnapshot = "nightly-2025-05-23" is hardcoded, I'm happy to accept a PR bumping it to the latest Stackage Nightly or implementing a more flexible scheme. The reason it is hardcoded, I believe, is that there used to be an issue with Stackage server with not all snapshot endpoints available in JSON format. Perhaps it has been fixed and we can just pick up the latest?..

Secondly, you can download any cabal.config you like (say, https://www.stackage.org/nightly-2025-11-12/cabal.config) and use it by specifiying --snapshot-path. And if boot libraries have been upgraded in the GHC source tree, you can edit them manually in the downloaded cabal.config.

Copy link
Contributor

@tbidne tbidne Nov 14, 2025

Choose a reason for hiding this comment

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

You're right; the minor version issue is extremely annoying. While upgrading this to 9.12.2 on my local branch, I added boot packages to excluded_pkgs.json, which should at least alleviate that problem (this probably needs to be done even when they become re-installable, as ghc is in the build plan).

Separately, changing stackageSnapshot = "nightly" and removing generated/cabal.project's index-state sounds plausible, though there are some nuances.

  • In general, a new major snapshot brings a bunch of new packages that need to be excluded -- e.g. they contain system deps or are executables -- so at some point nightly will not be buildable here, until a PR is made to add such packages to excluded_pkgs.json. At the present, this type of error would likely not be caught by CI, since the list of packages built by CI is necessarily very short.

    We could add a test that in fact runs clc-stackage with everything and --dry-run. This is quite fast and would detect both the errors above, since they are solver errors. It wouldn't detect actual build errors (hopefully stackage itself would?), but maybe it's good enough.

  • You'd still need to signal to users which ghc to use. I guess the readme could say "look at ci.yaml", or whichever ghc the latest nightly snapshot corresponds to.

  • I'm not sure what stackage's policy is, but lts might provide a more stable hardcoded path e.g. https://www.stackage.org/lts or https://www.stackage.org/lts-24 (resolves to the latest 9.10). The latter would require someone to bump it every so often, but you'd probably want to do that anyway for ci.yaml.

may ship different boot libraries. Mind that you want to probably also use the default flavour (not e.g. `devel2` as that may also cause
issues)

2. Compile a patched GHC, say, `~/ghc/_build/stage1/bin/ghc`.

Expand All @@ -36,6 +38,8 @@ The procedure is as follows:
* You can interrupt `cabal` at any time and rerun again later.
* Consider setting `--jobs` to retain free CPU cores for other tasks.
* Full build requires roughly 7 Gb of free disk space.
* if the build fails with an error about max amount of arguments in `gcc`, run again,
but with smaller batch size. 250 worked well for me.

To get an idea of the current progress, we can run the following commands
on the log file:
Expand Down