| 21 Apr 2025 |
 Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
I wonder if the GCC refactoring could fix https://github.com/NixOS/nixpkgs/pull/399656#issuecomment-2814602431 lol Is the goal to enable LTO for everything? That seems risky for packages not written with LTO in mind (e.g., ld64 is prone to crashing when built LTO enabled). | 14:33:56 |
| Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
I wonder if the GCC refactoring could fix https://github.com/NixOS/nixpkgs/pull/399656#issuecomment-2814602431 lol * | 14:34:13 |
 Tristan Ross | In reply to @reckenrode:matrix.org
Is the goal to enable LTO for everything? That seems risky for packages not written with LTO in mind (e.g., ld64 is prone to crashing when built LTO enabled). Pretty much | 14:34:57 |
| Tristan Ross | We'll have to come up with something which can override the platform attributes in the stdenv to change the platform to disable LTO. | 14:35:45 |
 Grimmauld (any/all) | https://github.com/NixOS/nixpkgs/pull/394610
some preparations for pkg-config -> pkgconf, with discussion about how to add a hook that should probably be default. Feedback would be appreciated. | 14:38:03 |
| Tristan Ross | I just realized that I could change the CC wrapper and add an optional thing to enable or disable LTO | 14:42:56 |
 emily | it looks good in principle but it shouldn't land before 25.11 | 14:46:59 |
| emily | so haven't put effort into reviewing as I'm focused on 25.05 prep | 14:47:08 |
| Grimmauld (any/all) | ah fair fair | 14:47:18 |
| emily | the Darwin bootstrap stuff is awkward | 14:47:32 |
| emily | arguably this should just be in the bootstrap tools, although having ported it to Python makes that kind of impossible | 14:47:51 |
| Grimmauld (any/all) | its python-minimal, specifically to not do string manipulation in C. I understand python-minimal is available early enough? | 14:48:44 |
| Randy Eckenrode | Darwin bootstrap gets a fully functional Python in stage 1. | 14:52:34 |
| Randy Eckenrode | Redacted or Malformed Event | 14:54:36 |
| Randy Eckenrode | * Though having Python pulled into the stdenv is going to add it to the stdenv closure size. Darwin is already huge, so what’s another however many tens or hundreds of MiB. I don’t know about Linux. | 14:54:42 |
| Randy Eckenrode | Not sure why this should be in the bootstrap tools. Can’t it be built in stage 1? | 14:57:12 |
| Tristan Ross | Any objections to documenting platform tier support? | 21:45:32 |
| Tristan Ross | If not, we should discuss what the tiers look like and what each platform fits into. | 21:46:51 |
| emily | it's already documented | 21:51:46 |
| Tristan Ross | Wait, where? | 21:56:08 |
| emily | Nixpkgs manual | 21:56:20 |
| emily | first section, https://nixos.org/manual/nixpkgs/stable/#chap-platform-support | 21:56:35 |
| Tristan Ross | Oh, that's just a list of commonly supported platforms | 21:57:26 |
| Tristan Ross | Not a platform support tier list | 21:57:38 |
| emily | it links to the platform tier list RFC | 21:59:50 |
| emily | which was approved but failed to make complete contact with reality | 21:59:59 |
| emily | which is something like x86_64-linux Tier 1, aarch64-linux Tier 1.5, aarch64-darwin Tier 2, x86_64-darwin Tier 2.5, i686-linux Tier 3, everything else tier nothing | 22:00:48 |
| emily | RFCs are immutable so the appendix will never be updated, but in principle we have accepted the tiers themselves | 22:01:15 |
| emily | and they have quite detailed descriptions | 22:01:21 |
| emily | in practice the biggest tier distinction is just "used on NixOS infra" vs. "not used on NixOS infra" | 22:01:54 |
