| 28 Jun 2025 |
 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 |
| Randy Eckenrode | CMake? Are you sure? I’m pretty sure I’ve gotten deployment target mismatch warnings until I set it explicitly to match what I want it to be. | 12:54:50 |
| Randy Eckenrode | My preference would be for sysroots with text-based stubs generated on platforms that support them. AFAIK stubs are faster to link than binaries, and it would ensure the install names are correct. Having everything together in a sysroot also works better with Clang modules. | 12:57:33 |
| Randy Eckenrode | (Which Swift leverages heavily.) | 12:57:41 |
| emily | In reply to @reckenrode:matrix.org
CMake? Are you sure? I’m pretty sure I’ve gotten deployment target mismatch warnings until I set it explicitly to match what I want it to be. "If not set explicitly the value is initialized by the MACOSX_DEPLOYMENT_TARGET environment variable, if set, and otherwise computed based on the host platform." | 12:59:42 |
| emily | the issue is that a lot of builds set it manually | 12:59:49 |
| Randy Eckenrode | So if we specify it, it overrides theirs? | 13:00:21 |
| emily | yes | 13:00:32 |
| emily | In reply to @reckenrode:matrix.org
My preference would be for sysroots with text-based stubs generated on platforms that support them. AFAIK stubs are faster to link than binaries, and it would ensure the install names are correct. Having everything together in a sysroot also works better with Clang modules. I think many things hardcode .dylib and .so unfortunately | 13:00:58 |
