Add property(ies) to Context describing the target triple

[grynspan]

There are various scenarios under which it would be useful to be able to get the target triple, or components thereof, as defined by LLVM. Would be great if we could expose that information via Context to the package manifest.

[grynspan]

See also #7110.

[dschaefer2]

Can you be more explicit about the scenarios you're thinking where the manifest would need to know the triple?

I really worry about exposing this to the package manifest. As I dig into cross compilation scenarios especially for distributed systems that you probably want to build from a monorepo with a single package manifest with multiple triples, we'll likely need to make changes to how that works.

[grynspan]

For Swift Testing, having this information as a string (rather than forcing us to ask 20 questions with arch() and os() checks) would be useful for diagnostic purposes. For instance, when we get a bug report with a crash, it helps to know what the target architecture/OS is at-a-glance.

I can see this also being useful for manifest authors that need to change specific compiler settings depending on architecture, e.g. enabling/disabling ptrauth instructions on arm64 or opting out of AVX instructions on Intel (because you know you're going to deploy to chips that don't support them.) That doesn't necessarily require the same API, as we could augment .when() to allow for architectures and not just OSes.

[dschaefer2]

For Swift Testing, having this information as a string (rather than forcing us to ask 20 questions with arch() and os() checks) would be useful for diagnostic purposes. For instance, when we get a bug report with a crash, it helps to know what the target architecture/OS is at-a-glance.

That sounds like you need something at run time, not package resolution time.

I can see this also being useful for manifest authors that need to change specific compiler settings depending on architecture, e.g. enabling/disabling ptrauth instructions on arm64 or opting out of AVX instructions on Intel (because you know you're going to deploy to chips that don't support them.) That doesn't necessarily require the same API, as we could augment .when() to allow for architectures and not just OSes.

I'm definitely interested in extending where .when() can be applied and what types of conditions you can when on.

[grynspan]

That sounds like you need something at run time, not package resolution time.

I need the value at runtime, but package build time is when the value is determined. I can't just go ask the Swift runtime (for example) for the info because the triple used to build the Swift runtime may not match the triple used to build my package.

[dschaefer2]

That sounds like you need something at run time, not package resolution time.

I need the value at runtime, but package build time is when the value is determined. I can't just go ask the Swift runtime (for example) for the info because the triple used to build the Swift runtime may not match the triple used to build my package.

You can mix triples at link time?

[grynspan]

Perhaps not statically within the same module (maybe you can?) but a module compiled with triple arm64e-apple-macosx12.0 could link to one compiled with triple arm64-apple-macosx12.4 (in theory, anyway—I don't know offhand if that specific combination is valid.)

[dschaefer2]

I guess my main thinking here is that I don't want to lock us into only one triple for a build like CMake has. CMake's toolchain stuff is totally bolted on and limits its use in monorepos. We pass -triple to the compiler at build time, we could also set a macro but ideally the compiler itself sets a macro.

[grynspan]

I've reached out to the clang folks about setting a macro on their end, but I'm exploring all options here. :)