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

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

At the moment, cabal-install doesn't support hpack natively but if the project can be build with cabal-install, you can run hpack manually to produce the .cabal file and utilise dr-cabal after that :)

Hm thanks for that, could try out some of those ideas. Here's the github issue i opened for this: https://github.com/haskell/cabal/issues/8580

Would really love it if the Cabal documentation had this as its own, highly visible entry. I submitted a pull request to that end.

Sometimes cabal's output is confusing with regards to optimization levels: https://github.com/haskell/cabal/issues/6221

Direct link to changelog: https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.8.1.0.md

Using Nix: https://github.com/nh2/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...