[ANN] macaroni.nix - Windows x-compilation for Haskell games

Announcements
#1

I’d like to properly announce the tooling I’ve been using to cross-compile my Haskell games from Linux to Windows - macaroni.dev / macaroni.nix · GitLab

Fundamentally, macaroni.nix is just haskell.nix + some overlays to package certain native libraries for cross-compilation. I’ve been slowly adding support for more and more gamedev libraries with native dependencies. The current set of “officially” supported libraries are:

(fwiw - pure Haskell libraries already Just Work cross-compilation-wise with haskell.nix)

I’ve been developing and using this build tooling for several years now but have been holding out on sharing it broadly because it had some rough edges (e.g. any library or project that used TH that required DLL loading would hang due to an iserv bug).

But now I think it’s finally solid enough to release on an unsuspecting world :cowboy_hat_face: If you are doing Linux Haskell gamedev, now you don’t have to worry about wrangling a Windows build. And hopefully someday, the project will grow to support more target platforms.

There’s some documentation in the repo, and feel free to cut me an issue if you have questions, ideas, or need help. You can also find me in the Haskell Gamedev Discord.

Also, a big shout-out to the haskell.nix project. It does a lot of heavy lifting, and the contributors have been very helpful in the issue tracker.

13 Likes
#2

Thant’s very cool!

I have been using haskell.nix to provide Windows cross build for one of my more popular projects. It’s mostly a pure CLI, so as you write, it works great out of the box with haskell.nix.

Is there a chance that your work would not have to be discovered by a potential users, but simply work out of the box with upstream haskell.nix (or even upstream nixpkgs)?

3 Likes
#3

I definitely want to upstream all the changes I have to make. Mostly overlays that could be nixpkgs PRs. haskell.nix issues I do tend to cut issues / PRs for.

But the project would probably remain. It’s a lot easier for me to just manage overlays than manage upstream changes. Especially since upstream maintainers have different goals than I do, so regressions around packaging feel inevitable if I just track & contribute upstream, especially as the project grows both in library and platform support. It’s pretty easy for people to introduce subtle changes to packaging that aren’t cross-aware. So I’m probably always going to be managing a “frontline” of overlays and patches to ensure my projects still work.

I guess I could manage forks of upstream projects instead that slowly flow into the upstream mainline. But that also seems a bit more annoying for me to do :sweat_smile:

3 Likes