Remove GHC 8.10.2, 8.10.3, 8.10.4 and 8.10.5 (after the hls release including GHC 8.10.7)

[Ailrun]

Currently, GHC 8.10.5 in macOS experiences https://gitlab.haskell.org/ghc/ghc/-/issues/19968 in our CI (and in @konn's Mac), so we cannot replace GHC 8.10.2 with GHC 8.10.5 as planned in #1898.

We may be able to remove GHC 8.10.2 after GHC 8.10.6 with the fix above.

[mouse07410]

The mentioned problem only surfaces if Xcode Command Line Tools package is installed. On machines with Xcode.app only (which also provides command line tools!) this problem https://gitlab.haskell.org/ghc/ghc/-/issues/19968 is not present.

[Ailrun]

@mouse07410 Thank you for the information! @konn, could you check you can build HLS without that package? Or is that package necessary for some other things?

[mouse07410]

. . . build HLS without that package?

Trivial - with one caveat. On MacOS you need either Xcode.app or CLT installed.

Or is that package necessary for some other things?

No, CLT package is not necessary - unless one insists on not installing Xcode.app.

Something has to provide Clang, header files, and libraries - they come either from Xcode, or from CLT. It turns out that CLT (for reasons beyond my understanding) is often (always?) more buggy and less usable than the "main" app that also adds GUI IDE...

[jneira]

Mmm, we are using github action envs to build the release and it failed so we could check if that library is installed there.
In that case we could:

• try to change the libraries installed in the images used by gha
• build locally the version in some macos and upload it manually to the release (like we do with 8.8.4 and windows)

[mouse07410]

we are using github action envs to build the release

Unfortunately, I've zero experience/expertise on GHA. But with some digging, it seems that GHA provides

Xcode Command Line Tools 12.4.0.0.1.1610135815

But it also seems to have Homebrew Clang-12 and Xcode_12.4.app - see the screenshot below.

Also, I tried with CLT 12.5. Your GHA used CLT 12.4. Both failed.

Proving that CLT is the problem, for which we need either a workaround (I've no idea how), or a bypass.

IMHO, you could be either referring to stuff in /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk (underneath this directory path, look for usr/include/ and usr/lib), or using Homebrew-installed Clang-12 as shown above.

. . . and it failed

Would be nice to see what the cause/complaint was. Perhaps you could post the summary/excerpt?

. . . so we could check if that library is installed there

Perhaps one can search in the above places for that library (which library is it, BTW?)?

[konn]

@mouse07410 Thank you for your information! That helps a lot!

@Ailrun I've just confirmed that network package just builds after sudo rm -rf /Library/Developer/CommandLineTools (which is the official way of uninstalling CLT).
With this workaround, it seems that HLS also builds with GHC 8.10.5 on my environment.

[Ailrun]

@konn Awesome, could you upload that version for this release?

[konn]

Sure. Just uploading executable built with stack with the proper name would suffice? Is there any description for the uploading procedure?

[Ailrun]

I guess @jneira knows well about that, as he uploads Windows binary regularly.

[jneira]

Sure. Just uploading executable built with stack with the proper name would suffice? Is there any description for the uploading procedure?

Yeah, the tar and the file contained in it have to follow the exact name schema as other ones. You can take as example the names of the existing one for ghc-8.10.4 and change the version.

Then you edit the release and attach the new file and the end of the editing form.