| 20 Jan 2025 |
 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 |
| emily | (defaulting based on platform is probably fine too although ideally we wouldn't assume that x86_64-linux means GCC etc. in the long run) | 02:25:42 |
| Tristan Ross | If I want multiple lib.warnIf with the oldest supported release thing, I could use lib.pipe so I don't have to put things in parentheses? | 02:31:13 |
| emily | I use assert …; for that stuff. but I think you'd want to get things wired up before actually expecting people to set it per ^, otherwise it'll be one very big PR | 02:32:39 |
| Tristan Ross | Oh | 02:32:52 |
| Tristan Ross | It wouldn't even take effect until 25.11 | 02:33:36 |
| emily | well, ideally we can get the prep done before the 25.05 release :) | 02:36:59 |
| emily | splitting it up will probably help with that | 02:37:11 |
| Tristan Ross | Yeah | 02:37:22 |
| Tristan Ross | Ok, the "legacy" use* has been wired up to set the new attributes and pkgsLLVM looks to work with that | 02:37:50 |
| Tristan Ross | Oh I've got good news | 03:08:03 |
| Tristan Ross | emily: the seccomp issue is not an issue anymore lol, checks work now | 03:08:21 |
| Tristan Ross | I didn't change anything lol | 03:08:33 |
| Tristan Ross | Upstream must've fixed it | 03:08:42 |
| Tristan Ross | Or it might've been a codegen bug? | 03:09:00 |
| emily | that's one fewer problem at least :) | 03:13:57 |
| Tristan Ross | Yeah lol | 03:14:32 |
| Tristan Ross | Cool pkgs/development/compilers/llvm/common/default.nix no longer depends on useLLVM | 03:18:40 |
| Tristan Ross | Just need to figure out why threadsCross has an optional for !useLLVM | 03:27:48 |
| Tristan Ross | And then we've got the rust mess | 03:27:54 |
| Tristan Ross | I've been able to adjust some other stuff thankfully because of bugs which no longer occur | 03:28:36 |
| Tristan Ross | I bisected the change to John Ericson (https://github.com/NixOS/nixpkgs/pull/73195/files#diff-ab5748dc9567516fefba8344056b51ec1866adeace380f46e58a7af3d619ea22R11302) | 03:31:14 |
| emily | I think that is just inherited from crossLibcStdenv, maybe. | 03:37:05 |
