| 20 Jan 2025 |
 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 |
| emily | as far as Rust goes, it's pretty hopelessly confused about cross-compilation / LLVM right now, so we will need rhelmot's PR and probably some additional work on top of that | 22:07:25 |
| 21 Jan 2025 |
| Tristan Ross | emily: How should we handle default values without using toolchain? Make everything null or should everything check what the platform is then set based on that? | 02:18:38 |
| emily | if following the incremental plan, everything would initially default to the value it currently has based on useLLVM etc. (and assert if anyone tries to specify something mismatching), and then in the final step they would become mandatory to set if not using the useLLVM back-compatibility shim | 02:21:01 |
| emily | (though presumably null is fine for freestanding platforms that don't care) | 02:21:08 |
| Tristan Ross | Oh | 02:21:41 |
