new package: ghcup-0.1.17.8

[kwshi]

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the quality requirements:

  YES:

  1. System-wide: ghcup is meant to be installed system-wide, even though it
     manages per-user installations of the Haskell toolchain (essentially
     analogous to rustup for Rust or opam for OCaml)

  2. Compiled: Yep

  3. Required (by other packages): no, but it's a very useful tool for Haskell
     developers, in the same way that rustup is useful for Rust devs,
     npm/pnpm/yarn is for JS devs, etc.

Local build testing

• I built this PR locally for my native architecture, (x86_64-glibc)
• I couldn't test build this PR locally for other architectures because,
  apparently, we can't cross-compile with Haskell yet.

[prez]

Is there anything that keeps this from getting merged? Thanks.

[kwshi]

As of recently, the build has starting breaking for me, presumably because Void has updated its GHC to 9.0.2 (9836c28), introducing some version-solving errors with ghcup's dependencies (which explicitly depend on a version of base older than the one included in GHC 9.0.2). I'm working on getting it fixed right now...

[hasufell]

You should print a post-install message like arch: https://aur.archlinux.org/cgit/aur.git/tree/ghcup-hs-bin.install?h=ghcup-hs-bin

[hasufell]

Here's a patch to fix building with GHC-9.0.2: https://gist.github.com/hasufell/164af24885c6f066291c417a9850388d

[kwshi]

I've applied @hasufell's patch and gotten the build to work; compilation on/to non-x86_64 architectures or musl unfortunately doesn't work currently because some of ghcup's dependencies are incompatible (e.g., haskell's libarchive package explicitly imports a glibc header). This package template is ready for review.

[hasufell]

I've applied @hasufell's patch and gotten the build to work; compilation on/to non-x86_64 architectures or musl unfortunately doesn't work currently because some of ghcup's dependencies are incompatible (e.g., haskell's libarchive package explicitly imports a glibc header). This package template is ready for review.

That can't be. The ghcup binaries are built on alpine linux with musl.

There's a static libarchive option: -f-system-libarchive

[kwshi]

I've applied @hasufell's patch and gotten the build to work; compilation on/to non-x86_64 architectures or musl unfortunately doesn't work currently because some of ghcup's dependencies are incompatible (e.g., haskell's libarchive package explicitly imports a glibc header). This package template is ready for review.

That can't be. The ghcup binaries are built on alpine linux with musl.

There's a static libarchive option: -f-system-libarchive

Weird-- I've tried building with -f-system-libarchive and the error still appears. The relevant error message, I think, is

c/archive_platform.h:84:10: error:
     fatal error: sys/cdefs.h: No such file or directory
       84 | #include <sys/cdefs.h>
          |          ^~~~~~~~~~~~~
   |
84 | #include <sys/cdefs.h>

Where all googled instances of sys/cdefs.h seem to point to GNU libc. The full error log on the workflow run is at https://github.com/void-linux/void-packages.

I've updated the package template to use -f-system-libarchive, and as you can see from the CI logs the same error still occurs; cabal is still trying to build the libarchive library, even though per my understanding it shouldn't (if we're using static libarchive).

I'll do some more investigation on alpine to see what might explain this disparity.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[kwshi]

bumping; still working on this!

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.