Support GHC-9.6 (rebased) #1127

hseg · 2024-09-11T11:33:04Z

Rebased version of #997 onto master.

Notable edits:

app/ghcup/Main:
- Update Cabal.Plan -> PlanJson -> GHCup.PlanJson
lib-opt/GHCup/OptParse/Common.hs: Reflect extraction of some parts to
lib/GHCup/Utils/Parsers.hs
Breakup of app/ghcup/BrickMain.hs
freezefiles:
- Picked up most changes from fix-hashable-mess, though see
  5b41f79 for doubts regarding my choices.
  Similarly, picked up some version bumps on the way (the unix freeze files
  are more affected by this).
  I'm least confident about this edit, it might require polishing
- Also picked up haskus-* -> variant
- UPDATE: Ended up regenerating these for unix, windows generation TBA once the other builds succeed
cabal.*.project:
- Given the commit for the tar repository that had been added is now
  released, I dropped the source-repository-package directive
- Picked up the hashable needing -arch-native
- UPDATE: Removed stale traces of cabal-{install-parsers,plan}
cabal.project.release:
- UPDATE: Removed the pinned tar commit, like in the other cabal.*.project files
- UPDATE: Removed stale traces of cabal-{install-parsers,plan}
- UPDATE: Removed stale traces of streamly and co
- UPDATE: Reorganized to follow the same order as the other cabal.*.project files
- UPDATE: Added the conditional ghcup +tar logic found in other cabal.*.project files
ghcup.cabal:
- Dropping cabal-{install-parsers,plan} in favor of Cabal-syntax and
  creation of GHCup.{CabalConfig,PlanJson,Utils.Parsers}
- Addition of parsec, utf8-string
- haskus-* -> variant
- optics moving into app-common-depends
- Extraction of ghcup-tui
- Removal of includes:
stack.yaml:
- haskus-* -> variant
- Use tar-0.6.3.0 instead of commit, pick up ghcup +tar flag
- Add mintty +win32-2-13-1 flag
Bumped tested-with to ghc-9.6.5 based on the existence of cabal.ghc965.*
macOS version bumped to 12
Deleted .orig files after it was confirmed they were unintentionally added.

Closes: #979, #997

hseg · 2024-09-11T12:35:32Z

Commentary on CI failures:

It seems .github/release.yaml and .github/workflows/shimgen.yaml should be upgraded away from upload-artifact@v2? https://github.blog/changelog/2024-02-13-deprecation-notice-v1-and-v2-of-the-artifact-actions/ I don't know Github workflows well, do you know how to update that?
I'm confused by the failures of cross.yaml:build and release.yaml:build-freebsd -- they complain about receiving a tar ==0.6.0.0 constraint, but git grep 'tar.*0.6.0.0 only yields the constraints tar ^>= 0.6.0.0 from ghcup.cabal

hseg · 2024-09-11T12:52:41Z

Ah wait, perhaps the remaining reference to the pinned commit of https://github.com/haskell/tar in cabal.project.release should be removed?

hseg · 2024-09-11T12:54:50Z

(note that the reference to a pinned commit in uri-bytestring is the as-yet-unmerged Soostone/uri-bytestring#64, so it can't be removed yet)

Original branch had freezes undone by 154a866 (hereafter: fix-hashable-mess), erred on the side of going with its newer situation. Doubts regarding my choices: - The `hspec` major versions have increased since to 2.11.* (over 2.10.* referred to there) See below where I kept the old version - `os-string` had a "bad" version 2.0.2.1 that was bumped everywhere, except in ghc{928,948}.Win32 where it had been at 2.0.2 -- it is unclear if that should've been bumped as well. Erred on the side of keeping those cases where the original branch had added `os-string ==2.0.3` given that that is the "good" version - Some dependencies were only touched in some freezefiles by fix-hashable-mess, so I kept the cases where they weren't touched around: - `hspec`: ghc*.Win32, excluding ghc965.Win32 - `tasty` and friends: ghc*.Win32, excluding ghc965.Win32 - `setenv`: ghc*.Win32, excluding ghc965.Win32 (I didn't know what the correct versions to use for ghc965.Win32 were, so I didn't try guessing)

Given the presence of cabal.ghc965.*, I assume that's the correct version to target

hseg · 2024-09-11T12:57:05Z

Hrm. I should probably not be force-pushing commits anymore now you're reviewing them, right? Sorry for that, will stop doing so if there are more modifications to be made. At least Github is smart enough to give you access to the diff between the two branch states.

hseg · 2024-09-11T12:58:56Z

Unfortunately, this still doesn't fix the weird tar ==0.6.0.0 bug -- any ideas where cabal is picking that idea up? EDIT: wait, the logs say
HEAD is now at d94a988 Codec.Archive.Tar.Read: refactor getEntry
-- is there still a reference to the commit somewhere?
EDIT2: Can't find any such references, very weird

hseg · 2024-09-11T13:06:22Z

BTW, it is unclear to me why these lines were removed from cabal.project.release in the original branch:

elif os(mingw32)
  constraints: zlib +bundled-c-zlib,
               lzma +static,
               text -simdutf,
               vty-windows >=0.2.0.2
  if impl(ghc >= 9.4)
    constraints: language-c >= 0.9.3

(Now, tbf they do occur in cabal.project, but mingw32 is the only platform that was previously duplicated there, and it is unclear why it was deduplicated in favor of cabal.project rather than cabal.project.release like linux, darwin and freebsd)

hseg · 2024-09-11T13:16:48Z

Wait, shouldn't I have dropped references to cabal-{install-parsers,plan}, given the migration away from it?

hseg · 2024-09-11T13:31:27Z

Oh wait, missed the existence of scripts/dev/refreeze.sh.
Should I be using that, instead? I don't have access to a windows box, so I can't create the windows freezefiles.

Cf fix-hashable-mess, presumably this should be added here as well

hasufell · 2024-09-11T13:55:24Z

I can handle the windows files. just update the unix ones

hseg · 2024-09-11T14:30:43Z

Missed one more migration: streamly -> conduit in cabal.project.release

hseg · 2024-09-11T14:33:29Z

Was 411ac8d supposed to affect cabal.project.release as well?
It guarded ghcup +tar behind an impl(ghc < 9.0)

This aids in diffing the two

Based on the behaviour of the other cabal.*.project files, introduced in 411ac8d. I'm presuming it was forgotten

hasufell · 2024-09-12T03:40:11Z

.github/workflows/cabal.project.yaml

@@ -20,12 +20,14 @@ jobs:
      fail-fast: false
      matrix:
        os: [macOS-12, windows-latest, ubuntu-latest]
-        ghc: ["8.10.7", "9.0.2", "9.2.8", "9.4.8"]
+        ghc: ["8.10.7", "9.0.2", "9.2.8", "9.4.8", "9.6.5"]


Why not 9.6.6?

Old branch was on 9.6.5, wasn't sure if you'd appreciate me bumping it.

hasufell · 2024-09-12T03:40:46Z

ghcup.cabal

-    , variant                ^>=1.0
-    , megaparsec             >=8.0.0    && <9.3
-    , mtl                    ^>=2.2
+    , aeson                 >=1.4


what's the point of reformatting here?

I'd noticed the spacing had ended up inconsistent after the last couple of edits there, and just blasted it with cabal-fmt. I can either drop this reformatting, take the less-noisy option of just realigning the outliers, or reformat it with gild to avoid such issues in the future. Your choice. (Also, please let me know if you'd prefer me just dropping/squashing the reformatting commit or if you'd like me to revert the reformatting on top of the current tip)

Just to make things concrete, I pushed a branch to my fork with the gild-formatted version of the cabal files. Let me know if it's in any way useful to you
https://github.com/hseg/ghcup-hs/tree/reformat-cabal

the reformatting makes it painful to fix merge conflicts

hasufell · 2024-09-12T03:42:31Z

cabal.project.release


 optimization: 2

-package ghcup
-  flags: +tui -tar
+if impl(ghc < 9.0)


This is not correct. The release project file always wants to build with -tar. The tar flag is only there to circumvent complicated errors during development, which sometimes happens due to libarchive.

Ah, OK. I'll drop a note in a commit reverting this, let me know if you want me to squash them together (so the resulting commit will just add a comment noting this discrepancy vs the other cabal.project files)

Also, is this why the mingw32 flags are present in cabal.project (and will be imported in cabal.project.release, whereas the linux, darwin, and freebsd flags are only present in cabal.project.release? Windows causes more trouble that needs to be caught at dev time, but the others are mostly just optimizations for release time?

hasufell · 2024-09-12T03:45:09Z

cabal.project.release

+    package ghcup
+        flags: +tui +tar
+
+constraints: http-io-streams -brotli,


Why add these when you already did import: cabal.project?

True, though by that logic, shouldn't cabal.project.release be simplified to:

import: cabal.project optimization: 2 if os(linux) if arch(x86_64) || arch(i386) package * ghc-options: -split-sections -optl-static elif os(darwin) constraints: zlib +bundled-c-zlib, lzma +static elif os(freebsd) constraints: zlib +bundled-c-zlib, zip +disable-zstd package * ghc-options: -split-sections

BTW, these constraints already existed at the bottom of the file -- I just moved them to the same place they were in the other cabal.project files

@hasufell

As explained by @hasufell > This is not correct. The release project file always wants to build > with -tar. The tar flag is only there to circumvent complicated errors > during development, which sometimes happens due to libarchive. Add a note citing the above to the file to prevent future mixups

Given that we import most of the configuration from cabal.project, there's no reason to duplicate it in cabal.project.release

hasufell · 2024-09-25T13:00:04Z

Can you revert the reformatting of the cabal files? Let's please keep the merge conflicts to a minimum.

hasufell · 2024-09-28T13:26:22Z

i squashed and rebased and set you as co-author in the commit, thanks: #1132

hseg · 2024-09-28T16:33:43Z

Thanks, have had much less free time in the past week, so I couldn't get back to you. El 28 de septiembre de 2024 16:26:45 GMT+03:00, Julian Ospald ***@***.***> escribió:

…

i squashed and rebased and set you as co-author in the commit, thanks: #1132 -- Reply to this email directly or view it on GitHub: #1127 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

hasufell and others added 7 commits September 11, 2024 15:55

Support GHC-9.6 wrt haskell#979

ed0fd9b

Fix macOS build

924194f

Attempt to fix darwin CI

81f30c8

Install coreutils and friends after all

91bcd84

Fix tested-with version

b16722e

Given the presence of cabal.ghc965.*, I assume that's the correct version to target

Reformat ghcup.cabal

48e6c87

hseg force-pushed the rebased-ghc-9.6 branch from 644f9ab to 48e6c87 Compare September 11, 2024 12:55

Remove last traces of cabal-{install-parsers,plan}

fe0c20e

Add hashable -arch-native to ghc-9.6.5

bf57a35

Cf fix-hashable-mess, presumably this should be added here as well

Regenerate unix freeze files

95c8aab

hseg added 3 commits September 11, 2024 17:35

Reorg cabal.project.release like cabal.project

b7a4d34

This aids in diffing the two

Remove last traces of streamly

d997c6c

Make release ghcup tar depend on ghc version

e4c2457

Based on the behaviour of the other cabal.*.project files, introduced in 411ac8d. I'm presuming it was forgotten

hasufell reviewed Sep 12, 2024

View reviewed changes

Update references ghc-9.6.5 -> ghc-9.6.6

3af2a82

hseg added 2 commits September 12, 2024 14:13

Remove redundancies from cabal.project.release

86b0c90

Given that we import most of the configuration from cabal.project, there's no reason to duplicate it in cabal.project.release

hasufell mentioned this pull request Sep 18, 2024

building ghcup with ghc-9.6/transformers-0.6 #1129

Closed

hasufell mentioned this pull request Sep 28, 2024

Support GHC-9.6 wrt #979 #1132

Merged

hasufell closed this Sep 28, 2024

hseg deleted the rebased-ghc-9.6 branch September 30, 2024 10:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support GHC-9.6 (rebased) #1127

Support GHC-9.6 (rebased) #1127

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024

hasufell commented Sep 11, 2024

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024 •

edited

Loading

hasufell Sep 12, 2024

hseg Sep 12, 2024

hasufell Sep 12, 2024

hseg Sep 12, 2024

hseg Sep 15, 2024

hasufell Sep 28, 2024

hasufell Sep 12, 2024

hseg Sep 12, 2024

hseg Sep 12, 2024

hasufell Sep 12, 2024

hseg Sep 12, 2024

hseg Sep 12, 2024

hasufell commented Sep 25, 2024

hasufell commented Sep 28, 2024

hseg commented Sep 28, 2024 via email

Support GHC-9.6 (rebased) #1127

Support GHC-9.6 (rebased) #1127

Conversation

hseg commented Sep 11, 2024 • edited Loading

hseg commented Sep 11, 2024 • edited Loading

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024 • edited Loading

hseg commented Sep 11, 2024 • edited Loading

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024 • edited Loading

hseg commented Sep 11, 2024

hasufell commented Sep 11, 2024

hseg commented Sep 11, 2024

hseg commented Sep 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hasufell commented Sep 25, 2024

hasufell commented Sep 28, 2024

hseg commented Sep 28, 2024 via email

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024 •

edited

Loading

hseg commented Sep 11, 2024 •

edited

Loading