update: K/N supported hosts #5154
Conversation
| | macOS (Apple Silicon) | ARM64 platforms | `macosArm64`, `iosArm64`, `tvosArm64`, `watchosArm64` | | ||
| | macOS (Intel chips) | x86_64 platforms | `macosX64`, `iosX64`, `tvosX64`, `watchosX64` | | ||
| | Linux | x86_64 platforms | `linuxX64` | | ||
| | Windows (MinGW toolchain) | x86_64 platforms | `mingwX64` | |
There was a problem hiding this comment.
On Linux and Windows we can compile all possible non-Apple targets, even with cinterops. With cross-compilation we can also produce .klib's from every supported host (the only restriction is custom cinterops on Apple targets)
danil-pavlov
force-pushed
the
native-host-support
branch
from
2f7e196 to
d7042bd
Compare
danil-pavlov
force-pushed
the
native-host-support
branch
from
d7042bd to
f81bdb0
Compare
docs/kr.tree
Outdated
| <toc-element toc-title="Binary options" topic="native-binary-options.md"/> | ||
| <toc-element topic="native-debugging.md"/> | ||
| <toc-element toc-title="Target support" topic="native-target-support.md"/> | ||
| <toc-element toc-title="Targets and hosts" topic="native-target-support.md"/> |
There was a problem hiding this comment.
Why not "Target and host support"? That seems clearer to me.
| | `androidNativeArm32` | `arm-unknown-linux-androideabi` | | [Android NDK](https://developer.android.com/ndk) on ARM32 platforms | | ||
| | `androidNativeArm64` | `aarch64-unknown-linux-android` | | [Android NDK](https://developer.android.com/ndk) on ARM64 platforms | | ||
| | `androidNativeX86` | `i686-unknown-linux-android` | | [Android NDK](https://developer.android.com/ndk) on x86 platforms | | ||
| | `androidNativeX86` | `i686-unknown-linux-android` | | [Android NDK](https://developer.android.com/ndk) on x86_64 platforms | |
There was a problem hiding this comment.
What is the motivation behind this change?
|
|
||
| The Kotlin/Native compiler supports the following hosts: | ||
|
|
||
| | Host OS | Architecture | Target compilation | `.klib` production | |
There was a problem hiding this comment.
The header seems confusing to me. It is not clear how "Target compilation" and ".klib production" map to "final binaries" mentioned below and in the cross-compilation documentation.
It makes sense to use the same terms everywhere.
There was a problem hiding this comment.
I agree, let's sync headers and the description below
|
|
||
| | Host OS | Architecture | Target compilation | `.klib` production | | ||
| |---------------------------|------------------|------------------------------------------------|------------------------------------------------------------------------| | ||
| | macOS (Apple Silicon) | ARM64 platforms | Any supported target | Any supported target | |
There was a problem hiding this comment.
Apple Silicon is the same as Architecture = ARM64 platforms. Let's merge this and the next lines and mention both architectures in the second column?
Or the opposite: remove the Architecture column, mention the architecture for any other OS in the first column. This makes sense because that would use the official terms for macOS (i.e. "Apple silicon" is more familiar than "ARM64 platforms").
There was a problem hiding this comment.
I merged the columns, but we use ARM64 with Apple targets everywhere in the targets section above, so I added it in parentheses as well
| |---------------------------|------------------|------------------------------------------------|------------------------------------------------------------------------| | ||
| | macOS (Apple Silicon) | ARM64 platforms | Any supported target | Any supported target | | ||
| | macOS (Intel chips) | x86_64 platforms | Any supported target | Any supported target | | ||
| | Linux | x86_64 platforms | Any supported target, except for Apple targets | Any supported target, Apple targets only without cinterop dependencies | |
There was a problem hiding this comment.
"platforms" is redundant in the second column.
"Architecture" is "x86_64", not "x86_64 platforms".
| | Linux | x86_64 platforms | Any supported target, except for Apple targets | Any supported target, Apple targets only without cinterop dependencies | | ||
| | Windows (MinGW toolchain) | x86_64 platforms | Any supported target, except for Apple targets | Any supported target, Apple targets only without cinterop dependencies | | ||
|
|
||
| * To produce final binaries, you can only compile supported [Kotlin/Native targets](#target-tiers) on supported hosts. |
There was a problem hiding this comment.
What does this mean? This kind of implies that I can produce final binaries for iosArm64 (a supported target) on Linux x86_64 (a supported host).
It is mentioned as not supported below, but this sentence itself suggests that it is, which seems confusing.
There was a problem hiding this comment.
Right, I rephrased it and moved the example closer to highlight that the 1st paragraph is about the fact that you cannot use any host that is not on the list. And the second paragraph here is specifically about Apple targets on Linux and Windows
|
|
||
| * To produce final binaries, you can only compile supported [Kotlin/Native targets](#target-tiers) on supported hosts. | ||
|
|
||
| For example, target compilation is not possible on the FreeBSD OS or on a Linux machine running on the ARM64 architecture. |
There was a problem hiding this comment.
Producing a .klib is also not possible.
|
|
||
| For example, target compilation is not possible on the FreeBSD OS or on a Linux machine running on the ARM64 architecture. | ||
|
|
||
| Compilation for Apple targets on Linux and Windows is also not possible. |
There was a problem hiding this comment.
Not clear how "Compilation for Apple targets" maps to "Target compilation", ".klib production" or "final binaries".
There was a problem hiding this comment.
Right, let's use the same terms as in the table
|
|
||
| Compilation for Apple targets on Linux and Windows is also not possible. | ||
|
|
||
| * Generally, Kotlin/Native supports cross-compilation, allowing any supported host to produce the `.klib` artifacts. |
There was a problem hiding this comment.
There was a problem hiding this comment.
I added the link to the bottom, but we also have the same information about cinterop-limitations here, so that users don't have to jump to another page.
No description provided.