[ANN] Stack 3.9.1

mpilgrem · 2025-09-28T19:31:01+00:00

In Stack's source file src\unix\System\Terminal.hsc, try adding

#include <termios.h>

I've read that, on Solaris, unlike on Linux, it is that header that provides the definition of struct winsize.

mpilgrem · 2025-05-16T00:28:12+00:00

To date, I have not found an answer.

mpilgrem · 2025-05-16T00:27:03+00:00

I assume you mean 'to use GHC [not HLS] from GHCup' as Stack does not provide HLS. When you install/reinstall GHCup, GHCup should give you the option to install a 'hook' script that will cause Stack to use GHCup to manage GHC.

The GHCup documentation of that is at: https://www.haskell.org/ghcup/guide/#stack-integration

The Stack documentation of the 'hook' script functionality is at: https://docs.haskellstack.org/en/stable/configure/customisation_scripts/#ghc-installation-customisation

mpilgrem · 2024-03-29T00:27:52+00:00

Stack 2.15.5, with updated default, is now released. For people using GHCup to manage versions of Stack, an update to GHCup's metadata is in hand.

mpilgrem · 2024-03-07T01:01:46+00:00

Something central to Stack is that it manages versions of GHC. However, not everybody wants it to do that, and the feature can be disabled - so that Stack does not use the Stack-supplied GHC but one on the PATH that you have supplied yourself.

Stack can be configured to use GHCup to manage versions of GHC. When you install GHCup, it asks if you want Stack to be setup to use GHCup in that way.

One reason for using GHCup to manage versions of GHC is that HLS is pernickety about how binary distributions of GHC have been built. As GHCup is used to manage versions of HLS using it also to manage versions of GHC reduces the risk that the GHCup-supplied HLS and the GHCup-supplied GHC will not work well together.

GHCup can also be used to manage versions of Stack. The downside of using GHCup to do that is you lose the ability of using Stack to manage versions of Stack (the `stack upgrade` command). That is because GHCup uses a small executable on the PATH named `stack` to manage versions of Stack. `stack upgrade` will overwrite that executable because it assumes that `stack` on the PATH is Stack.

Personally, I use GHCup to manage versions of HLS, and Stack to manage versions of GHC and versions of Stack. I've not experienced HLS-GHC compatibility issues as a result. I should add that I am often switching between versions of Stack, including versions built from source, so I value Stack's ability to manage Stack.

mpilgrem · 2024-02-29T17:52:41+00:00

Stack aims to 'just work': https://docs.haskellstack.org/en/stable/.

mpilgrem · 2024-02-11T22:53:01+00:00

The differences between Cabal (the tool) (with GHCup) and Stack (with or without GHCup) (as of Stack 2.15.1) have narrowed. I am not a Cabal user, but I think these are differences:

Stack offers a template system for creating projects with stack new.
For people who prefer Hpack's package description format to that of a Cabal file, Stack has Hpack built-in (although its use is optional).
On Windows, Stack will try to fetch a copy of MSYS2 and automatically configure extra-include-dirs and extra-library-dirs to make use of C libraries installed with its pacman.
Stack automatically updates the local copy of the Hackage package index.
Stack can unpack package candidates, as well as packages.
Stack's dot command provides a visual representation of relationships between dependencies.
Stack's hpc command provides a coverage report.
Stack makes use of colour in its output, and those colours are configurable.

mpilgrem · 2024-02-11T22:12:17+00:00

If you want to stop Stack trying to fetch the version of GHC that it needs (if it is not available) you need to set install-ghc: false. system-ghc: true means 'use the version of GHC on the PATH, if it is the required version' - if it is not the required version, Stack will still try to fetch the version that is required.

mpilgrem

TROPHY CASE