Cabal VS static-haskell-nix

Also, there's already a cabal RFC to support toml: https://github.com/haskell/cabal/issues/7548

Cabal has a lot of dark corners once you stray from the happy path. Just checked and I'm currently subscribed to 37 threads on the issue tracker, and I'm not a maintainer. A lot of these are related to lesser-used features like cabal scripts, environment files and doctests (though I think all of these things would used more if they were more reliable), but there's also plenty of stupid stuff like: - https://github.com/haskell/cabal/issues/3313 - https://github.com/haskell/cabal/issues/8527 - https://github.com/haskell/cabal/issues/8391 - https://github.com/haskell/cabal/issues/7789 - https://github.com/haskell/cabal/issues/6888 - https://github.com/haskell/cabal/issues/6999 - https://github.com/haskell/cabal/issues/5271

Given that Mike Pilgrim (the Stack maintainer) is on Windows, and Cabal has issues on Windows, I think it might be easier to get Windows specific fixes merged in Stack.

The error message is not too helpful. This is the target of a long-standing ticket: https://github.com/haskell/cabal/issues/7993 Your help would be very welcome.

By the way, there are some open issues for the command to add a package in Cabal.

That's interesting. Could you could open a an issue about this? https://github.com/haskell/cabal/issues

I created this issue a few months ago: https://github.com/haskell/cabal/issues/8270

Reported this as a bug in cabal.

We definitely plan to have benchmarks once we start working on performance. We haven't started yet because there were more urgent tasks. For example: ensuring that the testsuite runs on CI with the JS backend (should be completed this week or the next), ensuring that the toolchain works properly (we're writing a tutorial and we've found new bugs, e.g. yesterday I've fixed the support for js-sources in Cabal https://github.com/haskell/cabal/pull/8636), adding TH support...

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...