nixos/lib/eval-config: add buildPlatform attribute set

[Cynerd]

Description of changes

The new buildPlatform attribute set provides easy access to the cross compilation of NixOS. Platforms included in this attribute set are those exposed by Flakes.

The implementation supports both usage of nixpkgs.*Platform as well as nixpkgs.*System.

This is more or less a suggestion based on my experience of maintaining arm board running NixOS. The idea is to not hardcode build platform and rather let user to select it on build (the same way as it is for packages in flakes). The naming, as well as implementation, is of course, fully open to change on your suggestion.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[lovesegfault]

I don't think I understand the motivation for this, could you elaborate a little bit?

[Cynerd]

I don't think I understand the motivation for this, could you elaborate a little bit?

Sorry for the later response. I had a hard two weeks.

Anyway, the point is to allow simple-to-use specification of build platform for flakes. Currently, flakes provide packages in an attribute set where the user chooses the build platform (or it is auto-chosen by nix). In the case of NixOS, this is not simply possible without a little bit of Nix (extending with a module that sets the build platform). The point of this is to provide the ability to specify the build platform just simply by path while supported platforms are the same as for packages.

From my point of view the host platform is something that is given for the specific NixOS configuration while the build platform should be more on the user. I do not want to hard-code that you have to use x86_64-linux for example because that prevents NixOS building on other platforms (what if you have aarch64 laptop?). The result is that build platform is up to the user and when flakes are used I can't even decide which is the native platform to set a reasonable default. I have to choose something and default is that NixOS fallbacks on host and build platforms being the same.

One of possible usages is here https://gitlab.com/Cynerd/nixturris/-/blob/master/flake.nix#L46. I use it in NixTurris as well as in my personal flake to cross-compile NixOS for armv7l and aarch64 systems. The NixTurris is the only repository that converts NixOS to packages, I build others directly (https://gitlab.com/Cynerd/nixos-personal/-/blob/master/tools/common.sh#L82).

This is more or less just a suggestion as I wrote. Feel free to suggest a better solution, but my issue is that I want to be more generic about the build platform.

[infinisil]

I'm not a big fan of this because it works around two pretty bad related flaws in Flakes that should be fixed instead:

• Arguments can't be passed
• The problem with systems

[Cynerd]

I'm not a big fan of this because it works around two pretty bad related flaws in Flakes that should be fixed instead

It seems to be pretty decided that it is how it is with flakes, at least for now, until a new version of flakes is introduced. I am not sure if we should hope for some miracle and resolution of those issues or if we should just deal with flakes as they are. I can see the reasoning, but at the same time, I have to work with flakes as they are at the moment, and honestly I like flakes anyway.

[roberth]

A change in buildPlatform is a significant change to a configuration, so we shouldn't pretend that such a changed configuration is equivalent. Many packages take shortcuts when they get cross compiled, such as the omission of components and features, and almost always they go untested. While it could be argued that some buildPlatforms are morally equivalent if they're both sufficiently dissimilar to the hostPlatform, this is not a statement that applies to all buildPlatforms.
It is somewhere between a massive build impurity and a substantially different configuration, depending on circumstances, so switching buildPlatform shouldn't be taken lightly, and I recommend that you record changes to the buildPlatform in your flake's git history. For this purpose, the existing nixpkgs.buildPlatform is not only sufficient, but the best solution because it's simple, unambiguous and reproducible.