Depend on Cabal-3.14.*

[sol]

Using Cabal-3.14.* is one of the required changes for GHC 9.12. I need this for a personal project right now. The purpose of this PR is not to necessarily have it merged right away, but rather to avoid duplicated work when Stack upgrades to GHC 9.12.

@mpilgrem from what I understand, we don't want CPP to support multiple versions of Cabal, right?

Do we ever use a more recent version of Cabal than what ships with GHC? If "no", then this PR has to wait until we upgrade to GHC 9.12.

[mpilgrem]

@sol, there is no 'fixed' rule, but for a while I have based Stack's project-level configuration on Stackage's most recent LTS Haskell snapshot (currently, GHC 9.8.4) with, perhaps, a few extra-deps (to avoid bugs or to keep pace with hpack releases). In part, that is because it made updating all the tests when the snapshot changed a less painful exercise. (Having everything on the same snapshot used to be important because the old self-hosted runner on Linux/AArch64 only had sufficient space for one or two versions of GHC. Now, it is just a search-replace convenience to move everything forward together.)

Formally, the stack library exists only to serve the Stack executable, and so does not aim to build with anything other than the packages in the project-level configuration. As each version of Stack is built with only one specified version of GHC, CPP has not been needed.

Stack does not use its Cabal dependency to build. So, I have not experienced a pressing need to 'jump ahead' to build Stack itself against more recent versions of Cabal.

While the Stackage project has no direct support for GHC 9.12, I am a little reluctant to accelerate Stack's dependency on Cabal-3.14 but I would be happy to do that once Nightly moves to GHC 9.12. I assume that will happen once GHC 9.10.2 is released.

[sol]

While the Stackage project has no direct support for GHC 9.12, I am a little reluctant to accelerate Stack's dependency on Cabal-3.14 but I would be happy to do that once Nightly moves to GHC 9.12.

@mpilgrem great, that certainly works for me.

BTW, can you make sure that this settings is enabled under https://github.com/commercialhaskell/stack/settings?

[sol]

BTW, can you make sure that this settings is enabled under https://github.com/commercialhaskell/stack/settings?

Wait, maybe it's already enable, not sure. I think in this case the issue was that there were conflicts. I rebased manually.

[juhp]

Stackage LTS 24 has been out for a week now with ghc-9.10.2 :-)
And Nightly is on ghc-9.12.2: ideally it would be good to run CI/test using Stackage Nightly too.

Even better if stack were in Stackage Nightly generally, then it would automatically appear in LTS from day 0.

[juhp]

It seems stack-3.7.1 fails to build with ghc-9.10.2 though:

stack                        > [ 80 of 213] Compiling Stack.Storage.Util
stack                        > /var/home/petersen/tmp/stack-9db8faf780ea6faf/stack-3.7.1/src/Stack/Storage/Util.hs:31:36: warning: [GHC-12003] [-Wtype-equality-out-of-scope]
stack                        >     • The ‘~’ operator is out of scope.
stack                        >       Assuming it to stand for an equality constraint.
stack                        >     • NB: ‘~’ used to be built-in syntax but now is a regular type operator
stack                        >           exported from Data.Type.Equality and Prelude.
stack                        >       If you are using a custom Prelude, consider re-exporting it.
stack                        >     • This will become an error in a future GHC release.
stack                        >    |
stack                        > 31 |      ( PersistEntityBackend record ~ BaseBackend backend
stack                        >    |                                    ^
stack                        >

[mpilgrem]

@juhp, 6a672dd sets out the changes made to Stack's code to move from building against GHC 9.8.4 to GHC 9.10.2. There were only a few, import Data.Type.Equality ( type (~) ) was one of them. It caused me to raise:

• Export ~ of Data.Type.Equality? rio#255