Conversation
|
cc: @justice-adams-apple (can't add reviewers) |
|
@jakepetroules, do you see why I don't like using these env vars? It can become a mess, because they are hidden and apply globally to all local development, as opposed to config files that can be applied per-SDK or even per-target-triple. The log message I've been insisting that swift-build put out when choosing the NDK, if there's no config file, would greatly help users in situations like this. That said, @charles-zablit, the better solution here may be to only build that Swift package with NDK 28 or 29 with the nightly-main snapshots, as the trunk CI has switched to building the Android SDK itself with NDK 28c, and there is no guarantee that other NDKs will work. We plan to switch that trunk SDK CI to the upcoming LTS NDK 30, after which support for NDK 27 will likely be dropped, so might as well get ahead of that now. |
|
Better to close this, @charles-zablit, as though I've made clear my disdain for these env vars above, 😉 better to not hack around them like this, as I'm also removing the env var workaround we previously added in #246, once the next 6.3 snapshot is tagged. |
https://github.com/swiftlang/swift-tools-support-core/ fail to build because of the Pull request / Test / Swift SDK for Android Build (nightly-main - NDK r27d) (pull_request) job.
This is because of a version conflict betwen
ubuntu-latest's NDK and swift's one.