| 20 Jan 2025 |
 emily | it's possible some of the checks will end up checking the wrong thing but it's better than being able to do a check that defeats the point of splitting it up | 18:30:22 |
 Tristan Ross | Then we need a way to detect whether the toolchain is LLVM or not so the usingLLVM conditions can be translated. | 18:31:10 |
| Tristan Ross | * Then we need a way to detect whether the toolchain is LLVM or not so the useLLVM conditions can be translated. | 18:31:20 |
| emily | there's no such thing as "the toolchain is LLVM" | 18:31:23 |
| emily | that's what I keep trying to explain | 18:31:27 |
| emily | LLVM is a bunch of things and you can pick and choose which parts you use (compatibility permitting) | 18:31:36 |
| emily | hence Darwin using Clang, libc++, libc++abi, but ld64 | 18:32:15 |
| Tristan Ross | So then there's no such thing as a GNU toolchain? | 18:32:23 |
| Tristan Ross | I don't really see a simple way of defining what all the toolchain related things equates to. The toolchain attribute makes that possible. | 18:33:04 |
| emily | only as shorthand for "uses GCC, libstdc++, GNU binutils, etc.". I think that at one point FreeBSD was using libcxxrt but GCC? so is that "a GNU chain" | 18:33:14 |
| emily | * only as shorthand for "uses GCC, libstdc++, GNU binutils, etc.". I think that at one point FreeBSD was using libcxxrt but GCC? so is that "a GNU toolchain" | 18:33:15 |
| emily | (I could be wrong about the timing there, but there's lots of examples like this) | 18:33:15 |
| emily | if we want to keep having "an X toolchain" as a monolithic concept then we shouldn't add additional variables that can't vary freely because we assume all the things are grouped together | 18:33:33 |
| emily | if we want to split it up (which I think is a good idea and we should do it), then we shouldn't leave a vestigial notion around that will break actually trying to benefit from the split-up variables | 18:34:00 |
| Tristan Ross | That's kinda why I added a way to check if things are the default values. Then it's easier to see if the toolchain is the standard setup. | 18:34:26 |
| emily | either we keep "toolchain is GNU", "toolchain is LLVM", etc. (which already breaks down for things like Darwin), or we need to actually say what we mean i.e. "C compiler is Clang", "C++ library is libc++", "C++ ABI library is libcxxrt", "unwinder is libunwind", and continuing to have checks for "toolchain is LLVM" is just going to defeat the point | 18:34:43 |
| emily | because trying to actually deviate from the monolithic form will break as checks assume it still means something | 18:35:06 |
| emily | the backwards compatibility issue also needs addressing | 18:35:09 |
| Tristan Ross | What about the backwards compatibility? We already have asserts to make sure people move over to the new form. | 18:35:51 |
| Tristan Ross | I could add a set of attributes which exports as the using form and is based on the defaults. | 18:36:28 |
| Tristan Ross | So if the defaults for the CC, cxxlib, bintools, etc and the toolchain is LLVM then useLLVM could equate to true. | 18:37:11 |
| emily | that's not really acceptable for something this core, people need to be able to write code that works with both versions. you need to warn after the last version that doesn't support the new form is EOL and then convert it to an error a release later. see uses of lib.oldestSupportedReleaseIsAtLeast in the tree | 18:37:25 |
| Tristan Ross | Ok, that's doable. | 18:39:00 |
| Tristan Ross | @emily what about this for a compromise for the toolchain attribute? We stage the attribute set. So the first form is the defaults, 2nd is with user input applied, final is the adjusted form based on the inputs. Then we can handle if the toolchain deviated from the defaults, we can return null. | 18:42:28 |
| Tristan Ross | I don't see any other alternative option until we have the fine grain control and test every case (example is something like doCheck in pkgs/by-name/li/libseccomp/package.nix). | 18:43:35 |
| Tristan Ross | The benefit of staging the platform stuff is then we can get the fine grain control, handle non default cases, and still have things work as they do now. | 18:44:44 |
| emily | that means that there'll be conditionals for toolchain == "llvm" or toolchain == "gnu" that just fail if you try to vary any of the variables that they're shorthand for, because it'll become null despite actually wanting to check e.g. unwinder library. having a staging system that separates inputs and outputs so that toolchain = "llvm"; could be used as a shorthand but is never present in the final structure would be okay, but seems like a more major rework and probably not worth it just to save ~5 lines when you define a new platform | 18:45:29 |
| emily | we just have to investigate the existing ambiguous uses and figure out what they actually care about, whether that's through pinging maintainers, experimenting, or diving into the relevant source code. it's not necessarily easy, but it's what's required to actually make it a cleanup and deconfusing rather than just adding more non-orthogonal variables that won't actually work properly, which will make a bigger mess | 18:46:06 |
| emily | e.g. do libseccomp tests run successfully with Clang + libstdc++? with Clang + libc++? is it the unwinder? what errors happen when we try? | 18:46:40 |
| emily | having difficult-to-figure-out conditionals like this where it's not clear what they're checking for is the result of having overly-broad flags like the toolchain your PR adds | 18:47:11 |
