With Swift SDKs, we only set the following properties in the SDK if the input triple has a version:
- DefaultDeploymentTarget
- MinimumDeploymentTarget
- MaximumDeploymentTarget
For some platforms (like Android and Apple, and maybe FreeBSD), the version is essentially required. I'm pretty sure on Windows hosts it will cause build failures if an explicit version is not given... however we should be resilient against users passing (--triple *-unknown-android) without any version, and it's quite reasonable to do so if you don't know what API level you want to use.
For Apple platforms (which also hard-require a version) this isn't an issue because an absence of a version in the CLI triple, SPM falls back to what's defined in the manifest (but there's no version API for Android).
I think what we could do is add an extension point to allow a platform plugin to provide a default deployment target, and then non-Windows hosts can align with what Windows hosts are doing now, which is to default to the minimum API level currently supported by the NDK (21).
With Swift SDKs, we only set the following properties in the SDK if the input triple has a version:
For some platforms (like Android and Apple, and maybe FreeBSD), the version is essentially required. I'm pretty sure on Windows hosts it will cause build failures if an explicit version is not given... however we should be resilient against users passing (
--triple *-unknown-android) without any version, and it's quite reasonable to do so if you don't know what API level you want to use.For Apple platforms (which also hard-require a version) this isn't an issue because an absence of a version in the CLI triple, SPM falls back to what's defined in the manifest (but there's no version API for Android).
I think what we could do is add an extension point to allow a platform plugin to provide a default deployment target, and then non-Windows hosts can align with what Windows hosts are doing now, which is to default to the minimum API level currently supported by the NDK (21).