| 28 Jun 2025 |
 emily | people running exotic platforms can overlay things themselves | 13:28:29 |
| emily | I don't think it's worth a platform conditional considering that setting something unconditionally is a lot simpler all around | 13:28:47 |
 dramforever | to me it's more of a "cleanliness" of the solution over what we break | 13:29:06 |
| emily | I feel break is not the right word to use :) | 13:30:12 |
| dramforever | yeah because it's not | 13:30:26 |
| dramforever | * yeah because it's not breaking anything | 13:30:29 |
 Alyssa Ross | I don't think there's any real complexity to making this conditional? | 13:30:42 |
| emily | it's also not an exotic platform in general thing but just an x86 is the most register starved ISA in history thing | 13:30:44 |
| emily | In reply to @qyliss:fairydust.space
I don't think there's any real complexity to making this conditional? would it not be doable as just a flag to the rustc build otherwise? | 13:31:01 |
| emily | and forget about wrappers or Cargo or anything | 13:31:11 |
| Alyssa Ross | Oh, is it? | 13:31:11 |
| Alyssa Ross | In that case sure | 13:31:17 |
| dramforever | but i am annoyed by the fact that if we check targetPlatform in rustc it means there's a weird case where people cross compiling from x86-32 would find their build scripts and proc macros running with frame pointers enabled | 13:31:19 |
| dramforever | rustc wrapper, i mean | 13:31:42 |
| emily | targetPlatform is evil and we should not poison multi-target compilers with it any more than necessary :( | 13:32:02 |
| emily | I was just talking about the path to getting rid of wrappers for Clang in #stdenv:nixos.org | 13:32:17 |
| dramforever | sure, if only it was easy to check the actual target | 13:33:44 |
| emily | we shouldn't have logic like that at all beyond the native target configuration files LLVM and Rust supports | 13:34:25 |
| emily | anyway, doing things that work on every platform is good, but adding complexity that moves us away from things that can work upstream/without wrappera just to improve performance on systems we explicitly don't support out of a small legacy subset defeats the point of having guidelines about platform support IMO | 13:35:18 |
| emily | (if there's actually perf-relevant stuff in our supported i686-linux set like maybe parts of Mesa then that's another matter though, but I suspect not as good don't think we can even build Rust for i686-linux?) | 13:36:48 |
| emily | (as in the compiler. maybe we can) | 13:36:55 |
| emily | (I figured it would be one of those things that exhausts the address space) | 13:37:06 |
| Alyssa Ross | We could last I checked | 13:37:13 |
| Alyssa Ross | Which was probably a year or so ago | 13:37:32 |
| emily | do we actually on Hydra? | 13:37:40 |
| Alyssa Ross | No idea | 13:37:48 |
| emily | In reply to @emilazy:matrix.org
would it not be doable as just a flag to the rustc build otherwise? actually maybe not because of the Rust build forgets everything you tell it thing | 13:42:05 |
| emily | so wrapper injection may be unavoidable :/ | 13:42:20 |
| emily | at least until we do target configuration files | 13:42:37 |
| Alyssa Ross | Or we do it via build systems | 13:44:51 |
