| 26 Jul 2025 |
 raitobezarius | do it whenever it's convenient for you | 01:47:25 |
 Sergei Zimmerman (xokdvium) | Qyriad: | 12:02:58 |
| Sergei Zimmerman (xokdvium) | * Qyriad: What's up with the meson host_platform and cpu names? It's all very wonky and slightly broken I think (in both lix and cppnix). | 12:03:31 |
| Sergei Zimmerman (xokdvium) | The default system double in currentSystem is very f'ed up on 32 bit arm, mips, powerpc e.t.c. It's really a viscous cycle where nixpkgs determines the values in host_platform and the build system doesn't really use those correctly.
E.g. armv7l, armv6l translates to host_platform.cpu_family() = 'arm' in nixpkgs (as it rightly should). By the system double should differentiate between those, so it should look at cpu_name as well. | 12:07:40 |
| Sergei Zimmerman (xokdvium) | * The default system double in currentSystem is very f'ed up on 32 bit arm, mips, powerpc e.t.c. It's really a viscous cycle where nixpkgs determines the values in host_platform and the build system doesn't really use those correctly.
E.g. armv7l, armv6l translates to host_platform.cpu_family() = 'arm' in nixpkgs (as it rightly should). But the system double should differentiate between those, so it should look at cpu_name as well. | 12:08:59 |
 Qyriad | it probably should | 12:35:28 |
| Qyriad | that logic was translated directly from the old buildsystem | 12:35:40 |
| Qyriad | and at the time most of those targets didn't work anyway for Nixpkgs broken package reasons | 12:36:19 |
| Sergei Zimmerman (xokdvium) | Yeah, though is there any reason not to use hostPlatform.system when building nix with nix? | 12:38:34 |
| Sergei Zimmerman (xokdvium) | * Yeah, though is there any reason not to use hostPlatform.system when building nix/lix in nixpkgs? | 12:38:56 |
| Qyriad | Probably not? Have you tried it? Does anything break? | 12:39:19 |
| Sergei Zimmerman (xokdvium) | It should just work. I'll try to get the manual logic in meson to align with what https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/lib/meson.nix does (for the sake of other distros building nix). But for consistency lib.systems should just be the source of truth IMO. | 12:41:20 |
 emily | In reply to @xokdvium:matrix.org
The default system double in currentSystem is very f'ed up on 32 bit arm, mips, powerpc e.t.c. It's really a viscous cycle where nixpkgs determines the values in host_platform and the build system doesn't really use those correctly.
E.g. armv7l, armv6l translates to host_platform.cpu_family() = 'arm' in nixpkgs (as it rightly should). By the system double should differentiate between those, so it should look at cpu_name as well. 32-bit ARM can't even build Nix | 12:46:56 |
| emily | so I wouldn't worry overly much | 12:47:08 |
| Sergei Zimmerman (xokdvium) | Well you can build it cross (and hydra does build it). | 12:47:28 |
| emily | did someone fix it? it was broken very recently | 12:47:54 |
| emily | maybe only for v6/v5 | 12:48:02 |
| Sergei Zimmerman (xokdvium) | Not sure, nix hydra jobset has been building it for quite some time now. | 12:49:42 |
| emily | looks like it's in fact only ARMv5, whoops | 12:52:43 |
| emily | 32 bit support in Nixpkgs is usually half broken in general | 12:53:17 |
| Sergei Zimmerman (xokdvium) | Yup, but the PowerPC bringup work shows that it still should be fixed. | 12:54:36 |
| emily | sure :) | 12:58:30 |
| emily | my impression was that Nix matched the Nixpkgs platform support policy | 12:59:02 |
| emily | not sure if Lix has any declared tiers | 12:59:11 |
| Qyriad | Most of the time that a Lix build for a platform has broken it has been because of a downstream Nixpkgs breakage | 13:00:28 |
| Qyriad | though I think sometimes that might've been through dependencies CppNix didn't have | 13:01:24 |
 aloisw | There have also been a couple of instances where 32-bit specific bugs have been introduced in Lix. | 13:02:24 |
| emily | building is one thing, running is another :) | 13:03:35 |
| emily | (though at least most 32 bit bugs can be caught statically with sufficiently aggressive checking) | 13:03:56 |
| aloisw | The instances I'm thinking of were actually all build failures. I do not know whether it actually runs. | 13:04:44 |
