| 28 Jun 2025 |
 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 |
| emily | maybe we could write .pc files for literally everything including libc and then just have machinery to opt in to assembling fixed flag strings to shove into compilers and build systems based on a given set of packages?? | 12:26:18 |
 Randy Eckenrode | I would like to do it via target if possible since that appears to be what Apple prefers doing in their toolchains. | 12:48:04 |
| emily | isn't that what I said? maybe I misunderstand | 12:48:56 |
| Randy Eckenrode | Could we figure out a way to have a static sysroot and use it explicitly for static builds? | 12:48:57 |
| Randy Eckenrode | e.g., -target arm64-apple-macosx14.0 | 12:49:14 |
| emily | ah | 12:49:27 |
| Randy Eckenrode | That’s what SwiftPM and Swift Build do. | 12:49:57 |
| emily | i don't think that solves the fundamental issue I'm talking about | 12:50:03 |
| emily | but it's also not that big an issue | 12:50:12 |
| Randy Eckenrode | More that whatever we do for deployment target would do it that way rather than use -mmacosx-min-version. | 12:50:29 |
| Randy Eckenrode | Somewhat tangential I guess. | 12:50:37 |
| emily | right | 12:50:40 |
| Randy Eckenrode | Ideally, we would hook into the build system to communicate the deployment target. e.g., AFAIK, CMake isn’t using our environment variable. You have to set it explicitly. | 12:51:10 |
| emily | it reads from the non mangled var like everything else | 12:51:47 |
