| 20 Jan 2025 |
 emily | Randy Eckenrode's notion of native bootstrap as cross would help make bootstraps support more toolchains without causing a combinatorial explosion of special cases, I think | 19:06:19 |
| emily | though in practice there are likely to be infelicities | 19:06:25 |
| emily | if we end up stuck with multiple monolithic bootstraps that bake in a bunch of assumptions about what you set all the variables to then I think a separate field that explicitly signals that's what it's varying would be best as it would also make it obvious that it shouldn't be used for checks in regular packages | 19:07:48 |
| emily | but ideally that would be avoidable… the drift between native and cross bootstrap is already pretty sad | 19:08:03 |
| emily | cc John Ericson who I think was working on cleaning that stuff up in the past | 19:08:17 |
 Tristan Ross | Yeah, I'm not fully concerned with bootstrapping until the platform changes have been merged. | 19:10:00 |
| Tristan Ross | Maybe a single attribute which defines the bootstrap environment to use would make sense? I'm just not sure. My thinking was to use the toolchain attribute. | 19:11:27 |
| emily | you can bootstrap a native "all GNU" toolchain from an "all LLVM" bootstrap toolchain, just like our "all LLVM toolchain" will get bootstrapped from our existing "all GNU" toolchain | 19:13:18 |
| emily | in principle, native bootstrap gets a stdenv made from bootstrap tools (that may have Clang or GCC or whatever) and cross-compiles new stdenvs until all the bootstrap tools have been washed away | 19:13:28 |
| emily | so in theory the choice of bootstrap tools is orthogonal to what choices the end result makes | 19:13:41 |
| emily | in practice, it can be more complicated, and our current split native/cross bootstraps are probably rigid in ways that makes that a bit of a pain, but I don't see any reason to couple it tighter | 19:14:10 |
| Tristan Ross | Gotcha | 19:14:40 |
| Tristan Ross | Maybe we have a base bootstrap that changes based on CC and adjusts things in later stages to accommodate for the other variables? | 19:15:27 |
| emily | you can compile GCC with Clang and Clang with GCC, right? so nominally the choice of bootstrap tools is independent of what compiler you want to use in the final environment, though in practice we likely have assumptions that break if they don't match (unlike cross bootstrap which inherently has to handle it - which is why unifying the two more would be good) | 19:26:17 |
| Tristan Ross | I'm not sure if GCC can be compiled with Clang, I know Clang can be compiled with LLVM. GNU things tend to not like Clang or LLVM stuff in certain cases. | 19:27:27 |
| Tristan Ross | * I'm not sure if GCC can be compiled with Clang, I know Clang can be compiled with GCC. GNU things tend to not like Clang or LLVM stuff in certain cases. | 19:27:38 |
 Randy Eckenrode | In reply to @emilazy:matrix.org
Randy Eckenrode's notion of native bootstrap as cross would help make bootstraps support more toolchains without causing a combinatorial explosion of special cases, I think I don’t think I’m the only one with this idea. I’m pretty sure there is an open issue about it. Ideally, it should be possible to have a fully functional stdenv from just the bootstrap tools, then you can cross-compile to your target platform from there.
One thing that may be problematic is cc-wrapper’s suffix salt. You want bootstrap tools, first build, and final build to be treated as different platforms in spite of having the same salt. I also don’t know how the final cc can be used to build everything but its own dependencies.
| 19:30:03 |
| Randy Eckenrode | One thing I would not mind is if the various pkgs reflected the stages of the bootstrap. | 19:30:46 |
| Randy Eckenrode | They don’t right nowz | 19:31:15 |
| Randy Eckenrode | * | 19:31:25 |
| emily | I feel like we ought to just use hashes for salts. | 19:32:22 |
| emily | same platform different salt shouldn't be possible. | 19:32:35 |
| Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
I'm not sure if GCC can be compiled with Clang, I know Clang can be compiled with GCC. GNU things tend to not like Clang or LLVM stuff in certain cases. Darwin builds GCC with Clang. | 19:33:14 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
same platform different salt shouldn't be possible. Static builds. Darwin needs a static-aware salt because the build SDK is dynamic while the host SDK is static. | 19:34:27 |
| Tristan Ross | In reply to @reckenrode:matrix.org
Darwin builds GCC with Clang. Oh, I wasn't aware of that. I just know from experience with pkgsLLVM there's quite a few cases of using the gccStdenv | 19:34:59 |
| emily | yeah. if GCC couldn't build Clang we'd have no Clang on Linux. if Clang couldn't build GCC we'd have no GCC on Darwin. | 19:39:28 |
| emily | since those are what we bootstrap from in practice | 19:39:37 |
| emily | In reply to @reckenrode:matrix.org
Static builds. Darwin needs a static-aware salt because the build SDK is dynamic while the host SDK is static. yeah. which is why it should just be a hash of the whole thing | 19:40:06 |
| Tristan Ross | After today's discussion, I'm really unsure the direction to go for the lib.systems PR. I can add the backwards compatibility bit but regarding toolchain, I just can't think of any alternatives. It's kinda needed so the other attributes default, it also makes using pkgsLLVM without specifying pkgs to NixOS easier. | 20:33:36 |
| emily | we can just require all the attributes to be set. defining platforms is rare and it's good to be explicit. pkgsLLVM can do the same, what problems do you envision there? | 20:50:18 |
