Peeking at lib/systems/parse.nix, targetPackages.stdenv.targetPlatform.parsed.cpu.name looks more correct in most cases - for example, for riscv32 and riscv64 targetPackages.stdenv.targetPlatform.parsed.cpu.family is just riscv, but targetPackages.stdenv.targetPlatform.parsed.cpu.name is correct.

This is correct for x86_64 too - x86 would need to be special-cased, given cpu.name is i686 there, and while it might work, it's not guaranteed to stay, according to meson docs.

it's not guaranteed to stay, according to meson docs.

I'm not sure I follow, I don't see anything special about x86 in their docs, but I don't really know where too look.

Yeah I would make the condition something like:

if targetPackages.stdenv.targetPlatform.isAarch32 then "arm"
else targetPackages.stdenv.targetPlatform.parsed.cpu.name

there's a few more cases like powerpc, riscv, that we probably should handle, but this will take care of most cases.

I wanted to suggest using ….cpu.name for mesons cpu_family instead of what we get from ….cpu.family, as it seemed to fit better.

I did take a closer look:

….cpu.name is correct for the following meson CPU families:

• aarch64
• riscv32
• riscv64

….cpu.name is wrong for the following meson CPU families

• 32 bit arm flavours (the armv7*) ones at least
• i686 instead of x86
• powerpc / powerpcle instead of ppc
• `armv7l

I ignored the ones not available in nixpkgs via pkgsCross.

In general, this looks very messy, and hard to test / ensure to keep working.

I'd suggest to instead provide a fixed lookup table / lookup attrset in the meson drv, translating from parsed.cpu.name to mesons cpu_family.

You replied just as I was pushing a new revision :). Yeah I think the attrset approach might end up being better considering the different discrepancies.

Should the attrset only implement overrides from cpu.name, a missing attribute assumed to be the value of cpu.name or should the attrset list all known values, and a missing attribute be a throw?