Windows support

added scopeplatforms label

I think that key steps are 1) to have ghcup download and run the latest msys2 installer (not sure where the canonical source for this would be) and 2) to have ghcup then run cabal user-config -a to augment the cabal config file with the "magic lines" similar to:

extra-prog-path: C:\Program Files\Haskell Platform\8.0.2\msys\usr\bin extra-lib-dirs: C:\Program Files\Haskell Platform\8.0.2\mingw\lib extra-include-dirs: C:\Program Files\Haskell Platform\8.0.2\mingw\include

If the user-config mechanism isn't great, ghcup certainly can modify the config file itself by any mechanism it pleases.

Outside of that, there's just "get it running on windows at all" afaik.

added typeimprovement label

changed milestone to %0.1.15

changed the description

@randen would be good if you can add your summary/insights here

ghcup now builds on windows... there are some rough edges and I need do adjust some details about GHC installation as to not require ./configure on windows

https://stackoverflow.com/a/47380501 seems also relevant... I'm still not sure how exactly we want to manage msys2. As a component that's updatable? Which distribution do we need to fetch?

See the comment in "Note" here: https://community.chocolatey.org/packages/msys2/ Even chocolatey does not update msys2 itself. msys uses pacman to self-update. (Sadly, many windows users of ghc, including myself, are fairly msys2 illiterate and not great about doing these things ourselves, but it is nonetheless The Way, from what I see).

I can't speak to the correct distribution and definitive source for it, however...

For symlinks to work, we need developer mode... is there a way to detect whether developer mode is active?

stackoverflow suggests checking a registry key, which sounds right: https://stackoverflow.com/questions/41231586/how-to-detect-if-developer-mode-is-active-on-windows-10

not sure the easiest way to do that from haskell.

The official site for MSYS2 is https://www.msys2.org/ and their github repo also has built distros in their "releases", matching what is on msys2.org.

My understanding is that we will have ghcup download and install MSYS2.

From what I can glean, it seems projects like ours which need MSYS2 for their Windows-flavor (e.g., rust, python), use it only for building rather than needing to distribute. Or, they bundle only a subset (e.g., rtools for build R packages; git for Windows). Other projects where it is needed at the end user side, they just ask them to install it and provide the link. Rust seems to just include a few gnu build tools (a nerfed gcc, ld, etc.). Sometimes they solve the problem by making an MSYS2 pacman distributed of their product (e.g., Rust has a variant like that).

Ruby DevKit

However, Ruby does what Haskell Platform used to do (and with better flexiblity): one variant of their installer (the "DevKit") bundles a full MSYS2. They also have a slimmer Ruby-language-only, but it is not the recommended choice for first install, especially given that Rails requires the DevKit flavor, with all the linux-y tools, and that the DevKit is also needed to build certain gems and/or some of the linux-y libraries certain gems link.

The DevKit has an executable with a few commands, one is to "activate" or "enable" MSYS2, which adds its location to the PATH. It might (or could, in the future) do more than than, haven't checked.

They allow sharing of MSYS2 with other Ruby versions by the user manually moving the msys64 directory up one level, to the common folder of all the installed Ruby versions, and apparently, their toolchain that "activates" MSYS2 knows to look there first (or puts both on the PATH, with the common place first?), then to the version-specific subdirectory. So, nothing automatic for sharing but there is a path.

I would need to check more, but they also might add a few "batteries" to the MSYS2 distribution, as part of their bundle, to get a few more packages.

The Ruby project seems to have no qualms about the size of the DevKit, especially considering that it is done only once. They have recommendations about when to install to a new location, but presumably, anytime after the initial install, users can use the Ruby-only installer (rather than the DevKit flavor), couple with their above mentioned support for a (manual) way of having a shared MSYS2 install.

If we download MSYS2 during ghcup installation, we would need to use a static URL for this.

Maybe I misunderstood, but if not, then perhaps we should consider bundling MSYS2, rather than download, which resolves the URL issue and the 32-bit issue, but does make a much bigger download, at least for the initial installation.

32-bit MSYS2

Is 32-bit ghc currently supported for Windows? If so, we would need the 32-bit MSYS2. They no longer build a 32-bit MSYS2; their last build for 32-bit was their 2020-05-17 release. This would probably not be a real issue for our purposes, as the build tools needed are typically very common (on linux), relatively stable, well-established command-line utilities.

Updating MSYS2

gershomb, you raise a very good point about upgrading MSYS2: ghcup should install it once, and then never again. The note on the msys2 package at chocolatey.org says that MSYS2 will not be installed again or updated; that is up to the end user via pacman, after the initial install. Once pacman has modified the MSYS2 installation, the user wouldn't want ghcup to install something on top of that.

I haven't used it but there is the venerable and maintained System.Win32.Registry from the Win32 package.

Windows 7/8 support

What is the oldest version of Windows that ghc supports? If Windows 7 and/or 8 are still on the list, the developer mode of Windows 10 mechanism would need to be conditional. Also, the method of symlinking might not work the same on Windows 7/8 as on Windows 10.

Progress report:

Installation on its own seems to be working: https://imgur.com/a/rbZIWJh
I've created a #haskell-ghcup channel on Libera IRC (the successor of freenode)

WRT MSys2

So my idea would be this:

the installation of MSys2 would not be handled by the ghcup executable, but the ghcup bootstrapper (on linux, this is the bootstrap-haskell shell script... on windows, this would be an executable that launches an interactive powershell installation like rustup... I'd have to look into how they do that)
the bootstrapper would install MSys2 once and optionally
the bootstrapper would ask whether MSys2 be added to PATH or whether cabal.config should be adjusted

Whether the boostrapper should bundle MSys2 or download it... I have no idea. I'm not sure how to implement either currently, so that would need investigation.

WRT Symlinks and Win7/8 support

I'm not sure how feasible it is to rely on symlinks, but ghcup is designed around it and it would be quite annoying to have windows-specific workarounds. I'm also not sure how such a workaround would look like... just copying would require changes to how SET versions are discovered. Using a shell wapper script would be another option.

Note that cabal itself has code to generate powershell that performs a download, which can be cribbed from (https://github.com/haskell/cabal/blob/00a2351789a460700a2567eb5ecc42cca0af913f/cabal-install/src/Distribution/Client/HttpUtils.hs#L597) . As you note, I'm expecting that the bootstrap-haskell shell script would need to be ported to powershell in general anyway. Which seems like a key task, and also somewhat of a PITA though perhaps randy or tamar might be more familiar with how to do it.

If we're not confident in a stable upstream url, its easy of course to provide hosting for a msys2 to download from haskell.org servers.

So I believe now that the codebase of the current PR is in a usable state for starting with msys2 story, powershell installer and deciding on how to proceed with symlinks.

All bare tool installations work so far.

My experience with msys2 so far:

I installed MSys2 from http://repo.msys2.org/distrib/x86_64/msys2-base-x86_64-20210419.tar.xz into ~/.ghcup/msys64
I ran msys2_shell.cmd as the documentation outlines
I ran pacman -Syuu
I tried to run update-core as the documentation says, but it doesn't exist
I ran pacman -Sy, pacman -Suu and pacman -S mingw-w64-x86_64-toolchain
I restarted the powershell
I ran cabal user-config -a "extra-prog-path: $HOME\.ghcup\bin, $HOME\AppData\Roaming\cabal\bin, $HOME\.ghcup\msys64\usr\bin, $HOME\.ghcup\msys64\mingw64\bin" -a "extra-include-dirs: $HOME\.ghcup\msys64\mingw64\include" -a "extra-lib-dirs: $HOME\.ghcup\msys64\mingw64\lib" -f init
I tried cabal build on a project... and it picked the ghc shipped toolchain in ~/.ghcup/ghc/8.10.4/mingw, then failed with obscure hsc2hs errors
so I removed ~/.ghcup/ghc/8.10.4/mingw and tried again
now cabal says it cannot detect a mingw toolchain
I tried adding $HOME\.ghcup\msys64\mingw64\bin and $HOME\.ghcup\msys64\usr\bin directly to PATH and it didn't work either
I tried in powershell, mingw shell, nothing

So it doesn't seem any of the instructions are working.

This is just random speculation but it might be possible that some command (e.g., hsc2hs) is being launched/forked with a command line that is "too long", as the older/legacy Windows APIs had some limits we have hit in the past (e.g., given the long paths of cabal v2's hashed name structure, the command line can become much longer than with v1). If it is ok with you, I could take a look at this failure, if the ghcup branch you are working on is available for me to see.

I can also just try the commands you listed, independent of the ghcup part, so let me try at least as much as I can without ghcup right now.

Also, could be a mismatch between the environment and assumptions that cabal uses when executing in Windows OS versus the configuration you applied above with the user-config augmentations. I believe cabal would want/need Windows OS-style paths. That is, not the MSYS2 style, e.g., root with drives specified as "/C/". Cabal needs them in Windows-style, e.g., like "C:" and maybe cabal-install is ambidextrous about which was the slashes go (I can't recall; I need to check--but of course, MSYS2 only likes unix/linux-style path seperators). Or was the cabal.exe executed from the PowerShell?

@randen it seems to work when invoked like cabal build -w ~/.ghcup/ghc/8.10.4/bin/ghc.exe as opposed to cabal build -w ghc-8.10.4... which suggests it's a problem with symlinks

Windows support

Motivation

Implementation plan

Specification

Interface

MSys2

Installer

Child items ...

Activity

WRT MSys2

WRT Symlinks and Win7/8 support