haskell.nix VS static-haskell-nix

I'm not a great haskeller but I found haskell.nix better for Haskell projects, like the commenter on Discourse suggested. I've had a few issued regarding package versions with nixpkgs that haskell.nix solved.

FWIW, there's also libraries like haskell.nix that solve the caching problem.

I would try haskell.nix.

If you want to hurt your brain, check out haskell.nix. That's some good stuff right there ^^

The haskell.nix framework is good for this.

One cool thing is that this will enable GHC builds using ucrt instead of vscrt in the future. Concretely, together with NixOS/nixpkgs#171418 and its follow-up NixOS/nixpkgs#173498), this will e.g. allow haskell.nix to upgrade to a newer wine pin for TH cross compilation: https://github.com/input-output-hk/haskell.nix/blob/dd13e822529ae5342494969bce8a457522a60100/overlays/wine.nix

I've been using IOHK's alternative infrastructure for this reason. It has its quirks but I've been happier with it. Before that I think I was using developPackage from the nixpkgs haskell tooling which had some introspection ability. You may consider trying that out. But as I remember this will not abide by your version bounds.

There's a lot to like here. Alas, despite minimal dependencies, terminfo is somehow uniquely problematic in haskell.nix.

If you are somewhat comfortable with nix: https://github.com/input-output-hk/haskell.nix supports GHCJS 8.10.x (in particular 8.10.7).

Using Nix: https://github.com/nh2/static-haskell-nix

To debug this type of problem (I have to debug linker errors regularly as part of static-haskell-nix):

In static-haskell-nix there is currently this PR to enable support for that: https://github.com/nh2/static-haskell-nix/pull/108

I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs.

Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`.

> if they could keep that libgtk_static around

Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious.

> I'd be interested to hear if static linking GTK even has that many benefits

One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere.

Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed.

This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so.

[1] https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...

GTK can be statically linked.

Example executable:

https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...

It lost this ability temporarily when switching to Meson, but I fixed it in GTK3 and GTK4. But I just checked and apparently it is broken again:

https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109746...