Revive Stack build

[philderbeast]

Fixes #309. There's no Stackage snapshot for ghc-9.14.1, so set the snapshot via the compiler version and explicitly list all extra dependency versions, pretty much the same list as a cabal freeze would give.

Applies the workaround of renaming the internal dap library, commercialhaskell/stack#6920.

Note

Not tested on Windows.

[alt-romes]

Thanks @philderbeast!
Could you cherry-pick b97bc3a instead of your commit which renames it as dap-internal?

[mpilgrem]

To explain the existing approach:

• a custom 'GHC 9.14.1' snapshot built on top of nightly (with a revised compiler) is somewhat shorter than listing all the non-boot package versions;
• a distinct project-level configuration file is used for Windows (stack-windows.yaml), because of --enable-executable-dynamic (which is not applicable on Windows); and
• putting the custom snapshot into its own file (snapshot.yaml) reduces duplication between the Windows and non-Windows project-level configuration files.

[alt-romes]

I think mpilgrem's notes are quite important here ^

He had implemented the original Stack support and is a/the Stack maintainer.

[philderbeast]

The two approaches give slightly different stack ls dependencies, the dependencies when starting with nightly-2026-06-01 are on the left (in deps.txt) and those when starting with ghc-9.14.1 are on the right (in deps-cmp.txt):

$ stack --stack-yaml=stack.ghc-9.14.1.yaml ls dependencies > deps-cmp.txt
         
$ stack ls dependencies > deps.txt

$ diff --unified deps.txt deps-cmp.txt
--- deps.txt	2026-06-01 15:53:59.593133402 -0400
+++ deps-cmp.txt	2026-06-01 15:56:14.224346721 -0400
@@ -1,7 +1,7 @@
 Cabal 3.16.0.0
 Cabal-syntax 3.16.0.0
 OneTuple 0.4.3
-QuickCheck 2.16.0.0
+QuickCheck 2.18.0.0
 StateVar 1.2.2
 aeson 2.2.5.0
 aeson-pretty 0.8.10
@@ -13,7 +13,7 @@
 attoparsec 0.14.4
 attoparsec-aeson 2.2.2.0
 base 4.22.0.0
-base-compat 0.14.1
+base-compat 0.15.0
 base-orphans 0.9.4
 base16-bytestring 1.0.2.0
 basement 0.0.16
@@ -97,7 +97,7 @@
 safe-exceptions 0.1.7.4
 scientific 0.3.8.1
 semaphore-compat 1.0.0
-semialign 1.3.1.1
+semialign 1.4
 semigroupoids 6.0.2
 socks 0.6.1
 split 0.2.5
@@ -121,7 +121,7 @@
 time-manager 0.3.2
 transformers 0.6.1.2
 transformers-base 0.4.6.1
-transformers-compat 0.7.2
+transformers-compat 0.8
 typed-process 0.2.13.0
 unix 2.8.8.0
 unix-compat 0.7.4.1

Looking at versions only (but showing flags), the approach starting from snapshot: ghc-9.14.1 is closer to the dependencies fixed by cabal freeze in cabal.project.freeze:

$ cat cabal.project.freeze
active-repositories: hackage.haskell.org:merge
constraints: any.Cabal ==3.16.0.0,
...
             any.QuickCheck ==2.18.0.0,
             QuickCheck -old-random +templatehaskell,
...
             any.base-compat ==0.15.0,
...
             any.semialign ==1.4,
             semialign +semigroupoids,
...
             any.transformers-compat ==0.7.2,
             transformers-compat -five +five-three -four +generic-deriving +mtl -three -two,
...
index-state: hackage.haskell.org 2026-06-01T12:22:50Z

Building with the two Stack projects (first uses stack.yaml implicitly):

$ stack build --test --no-run-tests --bench --no-run-benchmarks
$ stack build --test --no-run-tests --bench --no-run-benchmarks --stack-yaml=stack.ghc-9.14.1.yaml

[philderbeast]

• a custom 'GHC 9.14.1' snapshot built on top of nightly (with a revised compiler) is somewhat shorter than listing all the non-boot package versions;

Basing it on nightly does give a shorter stack.yaml project file (or snapshot.yaml). I was hesitant to do that as nightly is a set of packages for a specific and different compiler version. The process of adding the extra-deps¹ for all of the non-boot packages, all 109 of them, was pretty quick. I just went through a few cycles of stack build and copied Stack's recommendations verbatim. Once it built, I sorted that list and dropped the @.. segment of each line (with :%s/@.*$//g in Vim), relying on the Stack-generated .lock file instead.

Footnotes

1. extra-deps of a stack.yaml needs to be renamed to packages within a snapshot.yaml. ↩

[philderbeast]

@mpilgrem, I powered up a Windows virtual machine that I haven't used in a while and tried the Windows build for both approaches but they both failed:

c:\...\haskell-debugger>stack build --test --no-run-tests --bench --no-run-benchmarks --stack-yaml=stack.windows.yaml
All test running disabled by --no-run-tests flag. To mute this message in future, set notify-if-no-run-tests: false in Stack's configuration.
haskell-debugger> build (lib + sub-lib + exe + test) with ghc-9.14.1
haskell-debugger> Preprocessing library for haskell-debugger-0.13.1.0...
haskell-debugger> Building library for haskell-debugger-0.13.1.0...
haskell-debugger> [13 of 29] Compiling GHC.Debugger.Monad
haskell-debugger> haskell-debugger\GHC\Debugger\Monad.hs:678:13: error: [GHC-83865]
haskell-debugger>     * Couldn't match expected type: IO ProcessHandle
haskell-debugger>                   with actual type: Win32-2.14.2.1:System.Win32.DebugApi.Internal.PHANDLE
haskell-debugger>                                     -> IO ProcessHandle
haskell-debugger>     * Probable cause: `mkProcessHandle' is applied to too few arguments
haskell-debugger>       In a stmt of a 'do' block:
haskell-debugger>         ph <- mkProcessHandle (fromIntegral pid) False
haskell-debugger>       In the expression:
haskell-debugger>         do bi_h <- socketToHandle sock ReadWriteMode
haskell-debugger>            pidLine <- annotateCallStackIO $ hGetLine bi_h
haskell-debugger>            pid <- case readMaybe pidLine :: Maybe Int of
haskell-debugger>                     Just pid -> pure pid
haskell-debugger>                     Nothing
haskell-debugger>                       -> fail
haskell-debugger>                            $ "invalid external interpreter PID on socket: " ++ show pidLine
haskell-debugger>            ph <- mkProcessHandle (fromIntegral pid) False
haskell-debugger>            ....
haskell-debugger>       In the third argument of `Control.Exception.bracketOnError', namely
haskell-debugger>         `(\ (sock, _)
haskell-debugger>             -> do bi_h <- socketToHandle sock ReadWriteMode
haskell-debugger>                   pidLine <- annotateCallStackIO $ hGetLine bi_h
haskell-debugger>                   pid <- case readMaybe pidLine :: Maybe Int of
haskell-debugger>                            Just pid -> pure pid
haskell-debugger>                            Nothing
haskell-debugger>                              -> fail
haskell-debugger>                                   $ "invalid external interpreter PID on socket: " ++ show pidLine
haskell-debugger>                   ....)'
haskell-debugger>     |
haskell-debugger> 678 |       ph <- mkProcessHandle (fromIntegral pid) False
haskell-debugger>     |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
haskell-debugger>

Error: [S-7282]
       Stack failed to execute the build plan.

       While executing the build plan, Stack encountered the error:

       [S-7011]
       While building package haskell-debugger-0.13.1.0 (scroll up to its section to see the error) using:
       C:\Users\...\AppData\Roaming\stack\setup-exe-cache\x86_64-windows\Cabal-simple_O_vy6YIf_3.16.0.0_ghc-9.14.1.exe --verbose=1 --builddir=.stack-work\dist\505eed1c build lib:haskell-debugger lib:dap-server exe:hdb test:haskell-debugger-test --ghc-options " -fdiagnostics-color=always"
       Process exited with code: ExitFailure 1

c:\...\haskell-debugger>stack build --test --no-run-tests --bench --no-run-benchmarks --stack-yaml=stack.ghc-9.14.1-windows.yaml
All test running disabled by --no-run-tests flag. To mute this message in future, set notify-if-no-run-tests: false in Stack's configuration.
zlib             > configure
zlib             > Configuring zlib-0.7.1.1...
zlib             > Error: [Cabal-7620]
zlib             > The program 'pkg-config' version >=0.9.0 is required but it could not be found.
zlib             >
Progress 1/5

Error: [S-7282]
       Stack failed to execute the build plan.

       While executing the build plan, Stack encountered the error:

       [S-7011]
       While building package zlib-0.7.1.1

[alt-romes]

Once Stack is revived, the instructions should be added back into the README (potentially by reverting 48ef569)

[alt-romes]

Could it make sense to wait for Stackage 9.14 to be out before trying this further? It feels like it would be much simpler.