| 20 Jan 2025 |
 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 |
| Tristan Ross | Maybe, I just think it's more convenient to have them inferred. | 20:52:12 |
| Tristan Ross | And we'll need to find cases where to replace *Platform.toolchain == with the appropriate case. | 20:54:22 |
| Tristan Ross | pkgs/development/compilers/llvm/common/compiler-rt/default.nix kinda needs it. | 20:55:17 |
| emily | it's more convenient in a very small handful of places but introduces a footgun everywhere | 20:55:19 |
| emily | which will ultimately make using alternative toolchains harder and more broken | 20:55:41 |
| Tristan Ross | Gotcha, maybe we use the backwards compatible use* until we can track down where things are and then switch the cases? | 20:56:31 |
| Tristan Ross | The use* would be based on the various attributes instead of the toolchain attribute. | 20:57:06 |
| Tristan Ross | So useLLVM checks if clang, compiler-rt, LLVM bintools, and libcxx are being used. | 20:57:34 |
| emily | we shouldn't use deprecated APIs in Nixpkgs - warnings will block the channel anyway | 20:58:35 |
| emily | surely it doesn't take more than a few minutes to just try building libseccomp with the various stdenvs and see which ones break? | 20:59:06 |
| emily | that needs narrowing down for an upstream report anyway | 20:59:36 |
| Tristan Ross | In reply to @emilazy:matrix.org
surely it doesn't take more than a few minutes to just try building libseccomp with the various stdenvs and see which ones break? libseccomp isn't the only problem, nix also breaks, krb5 also has a funky case | 21:04:42 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/243249 this is also a funky case | 21:06:18 |
| emily | well, still. you can throw Clang + libstdc++, Clang + libc++, etc. at them and narrow it down. (I forget if GCC + libc++ is possible) | 21:06:45 |
| emily | In reply to @rosscomputerguy:matrix.org
https://github.com/NixOS/nixpkgs/pull/243249 this is also a funky case looks like a temporary hack. hopefully we can get rid of it. but it looks like it might be conditioning on a non-libgcc_s runtime library maybe | 21:07:58 |
| emily | though if it works with FreeBSD but not those even today then maybe not | 21:08:20 |
| Tristan Ross | In reply to @emilazy:matrix.org
looks like a temporary hack. hopefully we can get rid of it. but it looks like it might be conditioning on a non-libgcc_s runtime library maybe Gotcha, so we can narrow it to the rtlib option instead of needing toolchain for this specific case? | 21:08:52 |
| Tristan Ross | I wonder how we should handle the Rust stuff in this PR. | 21:10:40 |
| Tristan Ross | In reply to @emilazy:matrix.org
well, still. you can throw Clang + libstdc++, Clang + libc++, etc. at them and narrow it down. (I forget if GCC + libc++ is possible) Oh fun, cxxlib isn't really wired up. Will have to figure out how to do that so I can test that. | 21:13:31 |
| emily | we already have stdenv for Clang and Clang + libc++ | 21:14:35 |
| emily | clangStdenv etc | 21:14:40 |
| emily | but we should probably also wire up the variables we're adding... :) | 21:14:59 |
| emily | In reply to @rosscomputerguy:matrix.org
Gotcha, so we can narrow it to the rtlib option instead of needing toolchain for this specific case? it'd need testing, but maybe. first I'd try just removing altogether | 21:15:16 |
| Tristan Ross | In reply to @emilazy:matrix.org
but we should probably also wire up the variables we're adding... :) Yeah, that's going to be fun figuring out. | 21:15:41 |
| emily | Tristan Ross: if you want to land this incrementally, my recommendation is:
- add the new variables solely as output-only, i.e., derive them from the existing
useLLVM etc. and assert that they are not set to anything contradicting those
- get rid of everything that looks at
useLLVM and so on in-tree, making them use the more precise variables instead
- make sure the bootstrap respects them and everything is wired up correctly (this should mostly be a matter of fixing existing conditionals on things like
useLLVM to determine what C++ library to set up and so on, I think; the various Clang stdenvs should help there)
- then, allow the variables to vary freely and start the deprecation of
useLLVM etc.
| 22:07:16 |
