[windows] Speed up installation further

Possible ways:

1. Pre-bootstrap an msys2 install with installed dependencies and then pack it up. Is this safe?
2. Don't use self-extracting archive, but .tar.xz or .zip. How to do this portably?

added scopewindows label

@Phyx ...do you know if it's possible to do the bootstrapping steps (including dependency install) of an msys2 distribution on e.g. CI/release machine, tar up the result and unpack that on the users machine? Are there any caveats?

@maerwald that's not really advisable. Msys2 mirrors the user's host environment. At first run files and configurations are copied from the host machine into the unix environment, the keyring is created and the file permissions are set based on the user's uid [1].

So if you do this on a CI machine and package that you'll end up with a stale keyring, and wrong configs for the user machine and with wrong file owner. You'll also end up with an incorrect nssconfig cache, which will affect users on e.g. a corporate network with Active Directory and/or web proxies etc.

To do this you'd have to remove and undo all the configuration and initialization that the first start scripts do.

[1] https://github.com/msys2/MSYS2-packages/tree/master/filesystem

@Phyx thanks, so right now the most time expensive step seems to be

Exec "$Bash" '-lc' 'pacman --noconfirm -S --needed git tar curl wget base-devel gettext binutils autoconf make libtool automake pkgconf python p7zip patch unzip'

Do you think that's too excessive? The idea was to have a reasonable set of deps, so you can run some autoconf stuff, can compile GHC from source and have access to pkg-config.

Well, does the average user need to be able to compile ghc? I would just make a script setup-ghc-dev.sh they can call instead.

Also you really don't want the msys2 versions of binutils and pkgconf etc. You want the native versions, i.e prefixed with mingw-w64-x86_64-otherwise these programs will enforce posix behavior rather than native Windows. I.e. pkg-config will return posix paths and give libraries linked against the cygwin runtime instead of the native OS one.

@bgamari so the action points are:

1. Remove the existing installation line https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/d9d196439ff1866c83e7a663dfa064674aff4748/bootstrap-haskell.ps1#L283
2. Replace it with just installing mingw-w64-x86_64-pkgconf and curl (I believe this is the minimum)
3. Place a shell script somewhere to install mingw-w64-x86_64-binutils and the others and somehow inform users that this may be needed to use the ghcup compile ghc feature. There can probably be several ways to do this.
4. Entirely remove the Quick script param https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/d9d196439ff1866c83e7a663dfa064674aff4748/bootstrap-haskell.ps1#L25 and all it's uses

I guess that should fix it?

Side note, why do you needs binutils? As part of the bootstrap process of GHC it installs its own copy of the toolchain which it uses to build.

Also host tools like current binutils no longer work with GHC (see #16780). You currently cannot use host tools in any part of GHC compilation.

mentioned in commit 7d3fb959

mentioned in merge request !105 (merged)

mentioned in commit e96c8631

closed

So, what has been done is this:

1. !105 (merged) which avoids installing expensive msys2 packages and places a desktop shortcut to install GHC dev dependencies, following @Phyx recommendations
2. Instead of asking questions throughout the whole installation process, we now ask them only at the beginning and then carry out downloads etc: !114 (merged)
3. Interactive installation is still the default, I believe this aligns with ghcup UX

mentioned in issue #200 (closed)