bb7229d224
leftover reporting. |
||
---|---|---|
.gitlab | ||
.travis | ||
app | ||
golden | ||
lib | ||
shell-completions | ||
test | ||
www | ||
.gitignore | ||
.gitlab-ci.yml | ||
.hlint.yaml | ||
.travis.yml | ||
bootstrap-haskell | ||
bootstrap-haskell.ps1 | ||
cabal.ghc884.project | ||
cabal.ghc884.project.freeze | ||
cabal.ghc8104.project | ||
cabal.ghc8104.project.freeze | ||
cabal.project | ||
cabal.project.freeze | ||
CHANGELOG.md | ||
config.yaml | ||
ghcup-0.0.2.yaml | ||
ghcup-0.0.3.yaml | ||
ghcup-0.0.4.yaml | ||
ghcup-0.0.5.yaml | ||
ghcup.cabal | ||
HACKING.md | ||
hie.yaml | ||
LICENSE | ||
README.md | ||
RELEASING.md | ||
Setup.hs | ||
stack.yaml | ||
TODO.md |
ghcup
makes it easy to install specific versions of ghc
on GNU/Linux,
macOS (aka Darwin) and FreeBSD and can also bootstrap a fresh Haskell developer environment from scratch.
It follows the unix UNIX philosophy of do one thing and do it well.
Similar in scope to rustup, pyenv and jenv.
Table of Contents
Installation
Simple bootstrap
Follow the instructions at https://www.haskell.org/ghcup/
Manual install
Download the binary for your platform at https://downloads.haskell.org/~ghcup/
and place it into your PATH
anywhere.
Then adjust your PATH
in ~/.bashrc
(or similar, depending on your shell) like so:
export PATH="$HOME/.cabal/bin:$HOME/.ghcup/bin:$PATH"
Vim integration
See ghcup.vim.
Usage
See ghcup --help
.
For the simple interactive TUI, run:
ghcup tui
For the full functionality via cli:
# list available ghc/cabal versions
ghcup list
# install the recommended GHC version
ghcup install ghc
# install a specific GHC version
ghcup install ghc 8.2.2
# set the currently "active" GHC version
ghcup set ghc 8.4.4
# install cabal-install
ghcup install cabal
# update ghcup itself
ghcup upgrade
GHCup works very well with cabal-install
, which
handles your haskell packages and can demand that a specific version of ghc
is available, which ghcup
can do.
Configuration
A configuration file can be put in ~/.ghcup/config.yaml
. The default config file
explaining all possible configurations can be found in this repo: config.yaml.
Partial configuration is fine. Command line options always overwrite the config file settings.
Manpages
For man pages to work you need man-db as your man
provider, then issue man ghc
. Manpages only work for the currently set ghc.
MANPATH
may be required to be unset.
Shell-completion
Shell completions are in shell-completions
.
For bash: install shell-completions/bash
as e.g. /etc/bash_completion.d/ghcup
(depending on distro)
and make sure your bashrc sources the startup script
(/usr/share/bash-completion/bash_completion
on some distros).
Cross support
ghcup can compile and install a cross GHC for any target. However, this requires that the build host has a complete cross toolchain and various libraries installed for the target platform.
Consult the GHC documentation on the prerequisites.
For distributions with non-standard locations of cross toolchain and
libraries, this may need some tweaking of build.mk
or configure args.
See ghcup compile ghc --help
for further information.
XDG support
To enable XDG style directories, set the environment variable GHCUP_USE_XDG_DIRS
to anything.
Then you can control the locations via XDG environment variables as such:
XDG_DATA_HOME
: GHCs will be unpacked inghcup/ghc
subdir (default:~/.local/share
)XDG_CACHE_HOME
: logs and download files will be stored inghcup
subdir (default:~/.cache
)XDG_BIN_HOME
: binaries end up here (default:~/.local/bin
)XDG_CONFIG_HOME
: the config file is stored inghcup
subdir asconfig.yaml
(default:~/.config
)
Note that ghcup
makes some assumptions about structure of files in XDG_BIN_HOME
. So if you have other tools
installing e.g. stack/cabal/ghc into it, this will likely clash. In that case consider disabling XDG support.
Env variables
This is the complete list of env variables that change GHCup behavior:
GHCUP_USE_XDG_DIRS
: see XDG support aboveTMPDIR
: where ghcup does the work (unpacking, building, ...)GHCUP_INSTALL_BASE_PREFIX
: the base of ghcup (default:$HOME
)GHCUP_CURL_OPTS
: additional options that can be passed to curlGHCUP_WGET_OPTS
: additional options that can be passed to wgetGHCUP_SKIP_UPDATE_CHECK
: Skip the (possibly annoying) update check when you run a commandCC
/LD
etc.: full environment is passed to the build system when compiling GHC via GHCup
Installing custom bindists
There are a couple of good use cases to install custom bindists:
- manually built bindists (e.g. with patches)
- example:
ghcup install ghc -u 'file:///home/mearwald/tmp/ghc-eff-patches/ghc-8.10.2-x86_64-deb10-linux.tar.xz' 8.10.2-eff
- GHC head CI bindists
- example:
ghcup install ghc -u 'https://gitlab.haskell.org/api/v4/projects/1/jobs/artifacts/master/raw/ghc-x86_64-fedora27-linux.tar.xz?job=validate-x86_64-linux-fedora27' head
- DWARF bindists
- example:
ghcup install ghc -u 'https://downloads.haskell.org/~ghc/8.10.2/ghc-8.10.2-x86_64-deb10-linux-dwarf.tar.xz' 8.10.2-dwarf
Since the version parser is pretty lax, 8.10.2-eff
and head
are both valid versions
and produce the binaries ghc-8.10.2-eff
and ghc-head
respectively.
GHCup always needs to know which version the bindist corresponds to (this is not automatically
detected).
Design goals
- simplicity
- non-interactive
- portable (eh)
- do one thing and do it well (UNIX philosophy)
Non-goals
- invoking
sudo
,apt-get
or any package manager - handling system packages
- handling cabal projects
- being a stack alternative
How
Installs a specified GHC version into ~/.ghcup/ghc/<ver>
, and places ghc-<ver>
symlinks in ~/.ghcup/bin/
.
Optionally, an unversioned ghc
link can point to a default version of your choice.
This uses precompiled GHC binaries that have been compiled on fedora/debian by upstream GHC.
Alternatively, you can also tell it to compile from source (note that this might fail due to missing requirements).
In addition this script can also install cabal-install
.
Known users
- Github action haskell/actions/setup
- vabal
Known problems
Custom ghc version names
When installing ghc bindists with custom version names as outlined in
installing custom bindists, then cabal might
be unable to find the correct ghc-pkg
(also see #73)
if you use cabal build --with-compiler=ghc-foo
. Instead, point it to the full path, such as:
cabal build --with-compiler=$HOME/.ghcup/ghc/<version-name>/bin/ghc
or set that GHC version
as the current one via: ghcup set ghc <version-name>
.
This problem doesn't exist for regularly installed GHC versions.
Limited distributions supported
Currently only GNU/Linux distributions compatible with the upstream GHC binaries are supported.
Precompiled binaries
Since this uses precompiled binaries you may run into several problems.
Missing libtinfo (ncurses)
You may run into problems with ncurses and missing libtinfo, in case your distribution doesn't use the legacy way of building ncurses and has no compatibility symlinks in place.
Ask your distributor on how to solve this or
try to compile from source via ghcup compile <version>
.
Libnuma required
This was a bug in the build system of some GHC versions that lead to unconditionally enabled libnuma support. To mitigate this you might have to install the libnuma package of your distribution. See here for a discussion.
Compilation
Although this script can compile GHC for you, it's just a very thin wrapper around the build system. It makes no effort in trying to figure out whether you have the correct toolchain and the correct dependencies. Refer to the official docs on how to prepare your environment for building GHC.
FAQ
- Why reimplement stack?
ghcup is not a reimplementation of stack. The only common part is automatic installation of GHC, but even that differs in scope and design.
- Why not support windows?
We do.
- Why the haskell reimplementation?
:-)