| 28 Jun 2025 |
 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 |
| emily | * | 12:11:11 |
