| 28 Jun 2025 |
 emily | I believe it should be possible to construct a basic LLVM toolchain for both Linux and macOS that does not use wrappers for at least Clang (less sure about things like LLD without more upstream work) and that completely ignores targetPlatform | 11:28:55 |
| emily | in the ideal case we have the individual configuration files for a target provided by separate packages and you can just pull whatever target you need into your build like that, which would allow a pkgsCross that doesn't need to instantiate an entire stdenv which might make @qyliss:fairydust.space happy :) | 11:43:50 |
| emily | though you would still have to assemble the fix point of course and I'm not sure if that's the expensive part currently | 11:44:17 |
| emily | (oh yes, and you could do NIX_CFLAGS_COMPILE by overlaying these config files with more parameters, although we really ought to do a lot less of it anyway) | 11:46:52 |
 Alyssa Ross | yeah it's virtually never necessary | 11:57:39 |
| emily | well | 12:01:05 |
| emily | it's necessary because it's how literally all C dependencies work right now | 12:01:15 |
| emily | there are of course multiple ways we could hopefully fix that though | 12:01:44 |
| emily |
- assemble sysroots for each build
- get Clang to support per-target C include path/etc. environment variables
- get Clang to support multiple search paths for target config files that can be overlayed together so packages can include the necessary flags in files in
nix-support
| 12:04:27 |
| emily | probably other ways I'm not thinking of right now too | 12:04:38 |
| emily | alternatively just expect everyone to use pkg-config and break cc -lfoo :P | 12:05:08 |
| Alyssa Ross | based | 12:05:14 |
| emily | agreed. you can handle the fallout | 12:05:32 |
 Qyriad | pkg-config + cmake flags + autotools flags would cover a lot of cases | 12:06:20 |
| emily | there's no uniform way to handle it for autotools that doesn't just reduce to injecting compiler flags again | 12:07:00 |
| Alyssa Ross | I'd much rather we have injected compiler flags that don't go behind the back of the build system | 12:07:18 |
| Alyssa Ross | Passing them to configure would already be an improvement. | 12:07:25 |
| emily | fair enough, but Clang target configuration files are all about passing flags behind the back of the build system | 12:08:01 |
| Alyssa Ross | eh, feels different when it's a supported compiler feature | 12:08:17 |
| emily | and I don't know where we draw the line. every compiler has built-in flags of some kind | 12:08:19 |
| emily | e.g. GCC specs | 12:08:22 |
| Qyriad | can't you --with-lib=/path/to/libfoo in most cases? I know well it's not universal but if you're breaking -lfoo anyway… | 12:08:22 |
| Alyssa Ross | You don't even need to. You can pass CFLAGS to configure or make. | 12:08:49 |
| Qyriad | good point | 12:08:58 |
| Alyssa Ross | (Although I guess it would be nicer not to) | 12:09:01 |
| emily | I doubt that's well-supported for e.g. libiconv (and it also doesn't work great with multiple outputs unless the autoconf build is especially nice) | 12:09:05 |
| Qyriad | yep fair enoughbutel | 12:09:45 |
| emily | In reply to @qyliss:fairydust.space
eh, feels different when it's a supported compiler feature sure. but hence a potential option is just having C/C++ stuff generate its own config file for overlaying | 12:09:50 |
| emily | I don't really have a strong opinion on the best way to handle it prior to experimentation but I feel like the best option for prototyping would just be to handle the existing flag variables and overlay them on top of the target configs in a setup hook | 12:10:53 |
| emily | you still bypass cc-wrapper's flag logix | 12:11:07 |
