feat: migrate to Nix Flake build system

[birros]

Hi everyone,

Having switched to Nix Darwin two weeks ago, I’ve fallen in love with this project, as it perfectly matched my requirements for rewriting the build system from scratch, which I've accomplished with this PR ^^

Here’s a summary of the main changes:

• The Makefile has been removed
• Most of the scripts have been rewritten directly within each package's default.nix
• The syntax of cross files has been improved
• The cross files are now also used as native files
• libpng has officially been added as a dependency. I discovered it was previously downloaded and compiled alongside freetype as a subproject

I haven’t modified any package versions or performed updates to ensure no regressions have been introduced.

---

@alexmercerind, @moffatman, @23doors I’m waiting your feedback or comments about this major migration. Additionally, please check from your side that no regressions have been introduced if this migration meets your approval.

Pros:

• Reproducible
• Sandboxed
• CI builds are 3.5 times faster
• Integrated caching system
• True dependency system
• Easier maintenance thanks to the use of a real programming language

Cons:

• Requires learning a new language
• Installation might be invasive for those who only want to use Nix for this repo (to be confirmed, as I use Nix for my whole system)

---

I started from scratch rather than pushing all of my local work because I was learning Nix simultaneously, so the commits were a bit… chaotic ^^

[alexmercerind]

LGTM!

I have very less understanding here.

[23doors]

Taskfile->Makefile->Nix Flakes

You do like rewrites 😉
Looks good but is it better? Well, your repo, your effort, your call. But to me its not that obvious. I liked all versions being in one place. Plus it is more confusing now to me as well. Not just cause of nix but also cause of quite a few package specific weird parameters, 2+ swift helpers that duplicate original behavior and such.

[birros]

Taskfile->Makefile->Nix Flakes

You do like rewrites 😉

Haha, not really, but I like writing maintainable code, meaning code that anyone can pick up if I’m no longer around. The current build system is more improvised than professional, and even I’m hesitant to update dependencies or modify the Makefile, so I can’t imagine what that’s like for someone else unfamiliar with it!

Looks good but is it better? Well, your repo, your effort, your call. But to me its not that obvious.

It’s definitely better, and for two main reasons: sandboxing and reproducibility. Those were goals I had from the beginning, but I lacked the know-how. Now we can maintain full control over the versions used, with macOS versioning being the only variable left, and its variability has close to zero impact. This setup also brings significant maintenance ease thanks to Nix, which is a programming language with many essential features out of the box. Maintaining a Makefile, on the other hand, requires using an unreadable or confusing syntax to implement features not originally intended. For example, $$(word 1,$$(subst -, ,$$*)) to extract the OS, whereas with Nix you can simply write { os }.

I liked all versions being in one place.

Do you mean you preferred having all versions centralized in downloads.lock? If so, I agree with you; I’ll look into centralizing them again, either in a single Nix file or a directory.

Plus it is more confusing now to me as well. Not just cause of nix but also cause of quite a few package specific weird parameters, 2+ swift helpers that duplicate original behavior and such.

I’ve made sure to use the tools available in Xcode.app and those provided in the NixOS/nixpkgs repo as much as possible.

• Unfortunately, plutil isn’t included in Xcode.app, and the only available package in NixOS/nixpkgs lacks the conversion functionality, plus it’s no longer maintained by Facebook
• However, xcodebuild is present in Xcode.app, but it crashes in Nix when sandboxing is enabled, and the version in NixOS/nixpkgs is in the same state as plutil. I preferred reimplementing the xcframework creation rather than disabling sandboxing

For both tools, I ensured they retain the same CLI syntax so anyone already familiar with plutil and xcodebuild would not feel lost. They’re written in Swift since the first one needs the Foundation framework for conversion, and the second just for the convenience of coding in Swift.