It seems like there is no great way to differentiate between i.e. a jetson (“aarch64-linux”), an aws graviton instance (“aarch64-linux”), or a nixos vm running on an M series mac (“aarch64-linux”). Is there a chesteron’s fence reason we don’t have a target triple in nix?
For all three targets you list the canonical vendor field would be set to unknown, so it wouldn’t actually help you distinguish between those targets either.
There are some vendors (e.g. nintendo-switch) that are still used, but typically the OS isn’t linux for those cases, so it’s very niche in a nixpkgs context.
The vendor field is pretty pointless in our day and age, since it rarely makes a difference in terms of target architectures. Any more specific optimization flags - to the extent that they matter, modern CPU architectures are designed around being efficient x86 processors, not selling bespoke features - are going to be too disparate between individual devices of a vendor for you to get much use out of a vendor-specific target. If you do want to offer builds for specific devices, you’re better off making that explicit by other means (nixpkgs does this through nixpkgs.hostPlatform).
The vendor field is optional by GNU spec as well. nixpkgs has just chosen not to bother maintaining a vestigial part of the spec.
Note that this does not apply to nix - nix itself doesn’t care about the target architecture at all, you could totally write a nixpkgs alternative that does use triples; this could even make sense if you targeted a more niche hardware ecosystem - nixpkgs, targeting generic MacOS and Linux, which are almost universally apple and unknown respectively, basically doesn’t get any use out of the vendor field.
Do you have a specific use case for this? Distinguishing between the targets you list is typically done at a deployment level, someone might be able to point you at what you need if you have a more specific question.
I don’t really understand your example. The three can run nearly the same set of programs, as we distribute them for the aarch64-linux platform, so having three different triples means that we build all software three times for no reason.
Nix itself supports additional required “flags” for scheduling derivations on machines depending on what the build process needs nix.conf - Nix Reference Manual
Nixpkgs supports even more complex configuration than a target triple. See: Nixpkgs Reference Manual
Can you give a more concrete example of what you want to achieve? “Use cross-compile triples” doesn’t really mean much.
1 Like
To me, it sounds like you missed the fact that there are multiple platforms. You can have build platform, host platform, and target platform all set to different things.