In future, could we standardise on one Stackage release/GHC version?
OsePedro opened this issue · 6 comments
If I'm not mistaken, a given package has to be recompiled from scratch when used within Stackage releases that provide different versions of GHC, even if those Stackage releases provide the same version of that package. This is tedious for big packages like OpenGLRaw and OpenGL (required by Gloss), which have 617 and 118 modules, respectively.
E.g. in the "Hackage" category, there are currently 5 games that depend on Gloss. subpar-hexagon, brickbreaker and vaders use lts-20 which currently resolves to lts-20.12, which provides ghc-9.2.6. But 1234-hero and guesscolor depend on lts-20.9 and lts-20.10 respectively, which both provide ghc-9.2.5. All three of these Stackage releases provide the same versions of Gloss, OpenGL and OpenGLRaw, but you have to compile these packages twice to play all 5 games, as shown by the following find results in ~/.stack:
~/.stack$ find -name '*OpenGL*.so'
./snapshots/x86_64-linux/421f31cfbd7a29fd9683b239ebe038ea7ed253a81c18c767587fdac3fe33f982/9.2.5/lib/x86_64-linux-ghc-9.2.5/libHSOpenGL-3.0.3.0-LpkQwsfDHdiHgHtEdDmdo8-ghc9.2.5.so
./snapshots/x86_64-linux/421f31cfbd7a29fd9683b239ebe038ea7ed253a81c18c767587fdac3fe33f982/9.2.5/lib/x86_64-linux-ghc-9.2.5/libHSOpenGLRaw-3.3.4.1-EPDWBO8k5lU2hca04RVt4R-ghc9.2.5.so
./snapshots/x86_64-linux/d7e924c9b9c52692b18ee42f62cc80a86679258c7d0639a498d53431e5dc77d0/9.2.6/lib/x86_64-linux-ghc-9.2.6/libHSOpenGL-3.0.3.0-Flc3feNJNdTH21QxlWEV9w-ghc9.2.6.so
./snapshots/x86_64-linux/d7e924c9b9c52692b18ee42f62cc80a86679258c7d0639a498d53431e5dc77d0/9.2.6/lib/x86_64-linux-ghc-9.2.6/libHSOpenGLRaw-3.3.4.1-6yRM0UvXpbbL51pZqbkStV-ghc9.2.6.soTo be clear, I had never built a Haskell project that uses OpenGL before playing the games in this contest, and I added -v to the Stack command in 1234-hero to confirm that Stack was recompiling the OpenGL packages after it had compiled them for subpar-hexagon. I haven't played all of the games yet, but presumably the freedom of choice will lead to more unnecessary recompilations across all of them.
To avoid this in future, and the related issue of having to install multiple GHC versions (I currently have five, whereas I only had one before the contest), could we standardise on one Stackage release and GHC version?
Would using nix be an option? It kinda solves this problem... but in a opinionated way!
@hellwolf I'm not familiar with nix. Is it a Docker-like ecosystem, where pre-built versions of packages (or even pre-built game submissions) can be downloaded from a central repository? If so then yes, I guess that would eliminate the need to do lots of recompilation locally.
Is there any reason why it would have been undesirable for the rules to have said everyone should build against a specific Stackage release/GHC version?
@OsePedro quite right, thanks for mentioning. I have now made all stack scripts use latest lts-20, so they are at least consistent. I have not retested every build, but I think this is very unlikely to cause new breakage, and if any it will be fixed before judging.
@simonmichael Oh ok, I was actually just thinking about future editions of the contest, but thanks for making some changes now! It might be better to specify say lts-20.12, because lts-20 points to the latest release in the LTS 20 series, which might provide a newer version of GHC in the future.
Oh actually, I don't know if specifying the minor version would break the line length limit in some cases.
PS and I agree building the haskell opengl packages is a horror, I wish someone could investigate/optimise those.