This PR doesn't include nix-systems/default, and hard codes supported systems... meaning riscv64-linux systems can't build this flake. Additionally there seems to be a typo for aarch64-darwin.

@Cammymoop @theoparis Good points from both of you.

I switched to an overlay-based approach. So maintainers can still manually curate a list of supported systems, but downstream users can (attempt to) build regardless of their architecture, and this way doesn't require an extra input.

Also changed BUILD_NAME to flake. For the typo... well let's not mention that 🙈

Hi @Naxdy,
I am a relatively new maintainer here, and am going back through all of the old PRs.
I see there are a few PRs here related to Nix packaging. While I am somewhat familiar with what Nix is, this is not my area of expertise.
Would you mind explaining your intended use case with this to better help myself and the rest of the team better understand what the benefits of providing upstreamed package definitions?
We are looking to make a final decision regarding this trio of PRs shortly. ( #954 , #247 , #154 )

Hi @Arctis-Fireblight , thanks for the inquiry.

I will only comment on my PR here, without comparing to the others. Please feel free to ask follow-up questions if you feel I'm being unclear. This PR is doing a couple things:

• It adds a Nix flake to the project. Flakes are a way of locking dependencies in Nix, though note that the only dependency this flake actually defines is the upstream nixpkgs monorepo, which is used for providing stdlib-like functionality in Nix, as well as a set of definitions for commonly used packaging, e.g. gcc

• It adds a package definition / derivation / build script (these terms are often used somewhat interchangeably, hence I mention them all) in the form of package.nix. In Nix, nativeBuildInputs refers to dependencies that provide executable files during build, e.g. gcc, and buildInputs refers to libraries. Most of the build script is taken from the godot one from upstream nixpkgs; going over everything in it would pretty much blow up this reply, so if you're really interested we can hop on a call or something.

  The package definition allows users of the Nix package manager to simply build the current repository without having to download any other dependencies, simply by invoking

  nix build .#redot --print-build-logs
  

  Nix will then download all required libraries and build tools, and start the build process. Moreover, the build is fully reproducible, meaning that given the same inputs and machine architecture, the result should (at least in theory) be bit-by-bit the same. Derivations for the Linux & Windows export templates are also provided, and can be built in a similar manner.

• The Flake also defines a "devShell". This is useful for those using the Nix package manager looking to develop on / contribute to Redot. By invoking nix develop . in a terminal, Nix will download all required build and runtime dependencies (tooling & libraries) and make them available in the user's PATH.

  This eliminates the need to manually hunt for things like gcc or necessary libraries, and ensures the provided versions exactly match those defined in the flake.nix (depending on which revision of nixpkgs the flake is currently locked to).

Note that "Nix" does not mean "NixOS", as Nix the package manager is completely distro-agnostic and can even be installed without any root privileges. It isn't even Linux specific, as a macOS version exists as well (Windows does require WSL though).

As you might be able to gather, building Redot this way would also be a prime candidate for CI, but only if there's interest from the maintainer side of course. There's also the option to cache built packages using a solution like Cachix, which we actually use extensively at my company, and even make the binary cache public, so other Nix users don't even have to build the packages locally if they don't change anything.

Nix also supports running unit / E2E tests as part of the build process, and actually does so out of the box when building Redot.

If you're worried about a potential future maintainer burden, I'd be happy to jump on the project as well, though I would strictly limit myself to maintaining the Nix builds and, if desired, CI.

I should also add that, while I am a package maintainer for nixpkgs, and would certainly support (and perhaps even initiate) an upstream effort for Redot, I think adding a flake definition still makes sense to a) be able to easily build the current dev branch, and b) for the dev shell functionality.

Let me know if you have any further questions!