@samuela can we create cabal bindists manually for the last few releases? It seems your PR will, at best, be merged after cabal 3.4 is released, according to phadej.
@maerwald Yeah, the main blocker AFAICT is Windows support. I don't have a Windows machine unfortunately but I think @bgamari on GitHub has volunteered to take that over.
I can take a look at manually creating bindists for ARM. I just kicked off the jobs for aarch64 and armv7. I think we should be able to simply pull the bindists out of the artifacts from those jobs. (Artifacts from the previous run just expired.) It'll be a pain to do this for past versions, but we can definitely start with bindists for the current one.
It'll be a pain to do this for past versions, but we can definitely start with bindists for the current one.
We need the exact versions. So what we could do is this: once we have a binary for "master", we write a job that simply does cabal install cabal-install-3.0.0.0 etc. and copy those artifacts over. We also need the plan.json files.
Hmm, ok I'm honestly not familiar with the Haskell/Cabal build systems at all, so I may not be the best person to do this. IUIC, you're saying we should use the current CI jobs eg for aarch64 to bootstrap a cabal binary. Then add new CI jobs to https://gitlab.haskell.org/samuela/cabal-build-test/-/blob/build-test/.gitlab-ci.yml to use that master binary to then build specific cabal versions, one CI job for each version, and each job outputting bindists as job artifacts. Is that correct? Where do the plan.json files come into play?
They're somewhere in dist-newstyle/ folder and @hvr wants these to be added to the cabal tarballs that get shipped (so we know how to reproduce said tarball).
So 3.0.2.0 and 3.0.1.0 are conspicuously absent, and versions before 3.x are ancient (full release history). Building 3.2.0.0 works without a hitch (that's currently what CI is doing). Building 3.0.0.0 does not work however:
ghc@1470d4eb689b:~$ cabal v2-install cabal-install-3.0.0.0 --installdir=$(pwd)/bin3.0.0.0 --builddir=$(pwd)/dist3.0.0.0 --install-method=copy --overwrite-policy=always --enable-split-sectionsResolving dependencies...cabal: Could not resolve dependencies:[__0] next goal: cabal-install (user goal)[__0] rejecting: cabal-install-3.2.0.0 (constraint from user target requires==3.0.0.0)[__0] trying: cabal-install-3.0.0.0[__1] next goal: base (dependency of cabal-install)[__1] rejecting: base-4.13.0.0/installed-4.1... (conflict: cabal-install =>base>=4.8 && <4.13)[__1] rejecting: base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0,base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,base-3.0.3.1 (constraint from non-upgradeable package requires installedinstance)[__1] fail (backjumping, conflict set: base, cabal-install)After searching the rest of the dependency tree exhaustively, these were thegoals I've had most trouble fulfilling: cabal-install, baseghc@1470d4eb689b:~$
Yeah, you need base-4.12.0.0, which is provided by ghc-8.6.5. You can also check ghcup list, which now shows the base versions next to ghc versions and you can even do ghcup install base-4.12.0.0.
But I guess I haven't added ghc-8.6.5 yet, so it won't recognise that.
Would 3.2.0.0 be enough? How important is 3.0.0.0?
I don't really know. But users have recently requested to be able to install multiple cabal versions in parallel, due to certain incompatibilities. Maybe this is, for ARM, a tiny use case, but it would be nice.
I'm also seeing that not all GHC versions have arm versions: https://downloads.haskell.org/~ghc/8.6.5/
Somehow, we need a way to retroactively trigger such arm builds for older tags. Or someone does that manually. Since I'm still on mobile phone bandwidth, I cannot mess with VMs right now. But I guess another way would be to just do all that manually in a VM.
Hmm, yeah now we're getting into the release process for GHC haha... So how does the GHC release process work? Can we add CI jobs for ARM to the GHC builds?
I agree it would really be nice to have first-class support for ARM. Just a matter of what that will require.
I don't have bandwidth to create ci-images for each of those combos, but if they come into existence I'd be happy to look into using them in the cabal CI.
I don't have bandwidth to create ci-images for each of those combos, but if they come into existence I'd be happy to look into using them in the cabal CI.
Well, I was hoping we can somehow just hijack this gitlab CI...
It would be fairly easy for GHC versions that have ARM builds (armv7 and aarch64) already. Unfortunately that rules out 8.6.5 and 8.8.3 though. They only have aarch64.
To be honest, I would probably rather we didn't offer ARM bindists for anything prior to 8.10. There are some very nasty bugs that were fixed in 8.10 and I think we should do everything we can to encourage users to upgrade.
Yeah, it should be totally possible! Unfortunately I just don't have the time to do it. But I'd be happy to update the cabal CI once such binaries are available though.
I still think doing this in CI (here or on github) is the ideal way to go. I think it just turned out to be hard to get buy in from others in the Cabal world. The only thing https://gitlab.haskell.org/samuela/cabal-build-test IIRC is windows support right now.