| 25 May 2025 |
Tristan Ross | In reply to @aleksana:mozilla.org hedgedoc time! Is that what pad.lassul.us is lol | 17:29:34 |
Tristan Ross | Is there someone here who could pin a message? I'm thinking it might be good to pin the link to the design doc on the new stdenv & CC improvements. | 17:36:37 |
Tristan Ross | Design doc on new stdenv & CC wrapper improvements: https://pad.lassul.us/mVkhtNyKSuCTqsiiCitwtA# | 17:36:58 |
Tristan Ross | Currently identifying the goals | 17:38:05 |
Tristan Ross | I've written a few steps down of things | 19:13:08 |
| Theo Paris joined the room. | 22:54:23 |
| 26 May 2025 |
Tristan Ross | In case people wish to join in and discuss all together the work on the stdenv & CC improvements, we have a crab.fit to figure out a good time. https://crab.fit/nixpkgs-stdenv-team-meeting-for-refactoring-906311 | 05:14:00 |
@trofi:matrix.org |
Split GCC up similar to LLVM to accomplish this
I would suggest getting llvm-only bootstrap on linux first :)
| 08:32:06 |
Randy Eckenrode | I can give feedback, but my time is still pretty limited, and what time I do have is focused on Darwin stuff. | 11:07:06 |
Randy Eckenrode | One cc thing I do want to do is rewrite Darwin version handling. It currently uses -mmacos-version-min, but Swift wants to do it via triple (e.g., arm64-apple-macosx14.0). I want to align the handling with what Swift wants to do. arm64-apple-darwin would become shorthand for arm64-apple-macosx with the current deployment target. | 11:13:24 |
Randy Eckenrode | (I also think emilyhad ideas for cc.) | 11:15:42 |
emily | FWIW, I tried -macosx and it sadly broke every autotools build system. | 11:20:32 |
emily | they only recognize -darwin. | 11:20:36 |
emily | (not sure why we are doing more calls after everyone else on the team said it's not a good fit…) | 11:21:01 |
emily | I also have pretty limited time right now (just moved, still very busy with it). hopefully will have more in a couple weeks | 11:21:44 |
Randy Eckenrode | In reply to @emilazy:matrix.org FWIW, I tried -macosx and it sadly broke every autotools build system. Can we use our autotools config hook to teach it macosx? | 11:29:49 |
Randy Eckenrode | Like we do for aarch64-darwin? | 11:30:05 |
emily | that only applies to old autotools versions right? | 11:34:54 |
emily | I think it would be possible, but I think I would want to upstream support for it to autotools | 11:35:05 |
emily | because if it's just a thing for old versions to backport something upstream is okay with, that's cool | 11:35:12 |
emily | but if we're patching every single autotools build in existence forever that's going to suck | 11:35:23 |
emily | it would have to be applied universally in stdenv until the update percolates through the ecosystem, before we can make it a standalone hook | 11:35:38 |
emily | it would be really nice to have arm64-apple-macosx14.x as the triple though, it would let us remove some hacks throughout the tree | 11:35:56 |
emily | we'd have to teach the GCC/binutils build about macosx* versions instead of just darwin* I think… or just get LLVM Flang packaged and give up on GCC on Darwin since we're already applying a ten billion line patch by one guy just to get it building… | 11:36:41 |
emily | oh I should also say: even Apple and LLVM are inconsistent about whether it should be -macos14.x or -macosx14.x. I forget which one is canonical. | 11:37:09 |
emily | I think libc++ passes one and Rust passes another and so on and so forth | 11:37:20 |