再一次过来帮大家踩坑了，Kotlin/Native 虽然很方便，但是坑依然不少，通过这一篇文章踩完吧，希望以后不要再碰到环境或编译问题了。
首先我依然要吐槽官方的新建项目向导，建出来几乎都是不能改的，目录都写死，一改就编不过去。后面就是干脆把 CLion 里的向导去掉了，这可怎么办才好:( 随后在升级了 IntelliJ IDEA 后发现，原来 Kotlin/Native 相关的东西都在这里了。亲儿子就是不一样啊，这么一看 CLion 简直是后妈养的。
在 IntelliJ IDEA 里新建一个 Kotlin/Native 项目，然后我们来说说 build.gradle。
plugins {
id 'kotlin-multiplatform' version '1.3.31'
}
这一段是对跨平台编译插件的引入，有一些教程上说需要引入 kotlin-native 插件，这是没有必要的，我也不知道是什么情况下才需要引用 kotlin-native 插件。
kotlin {
macosX64("macos") {
binaries {
executable {
entryPoint "main"
}
}
}
}
这一段用于指出在 Mac 下的编译方式，这里提供了编译为可执行程序的目标。这里还可以编译成别的东西，比如说 framework:
kotlin {
macosX64("macos") {
binaries {
framework {
baseName = "sample"
}
}
}
}
如果要实现跨平台编译，需要添加其他平台的 Target，比如说同时编译到 linux 下，可以增加这样的代码段:
linuxX64("linux") {
binaries {
executable {
entryPoint "main"
}
}
}
下面要讲的东西是重点中的重点，对于代码的配置，为什么 CLion 建立的项目不能乱改，很大程度上就是这部分的配置被写得太死。先来看这一段代码；
kotlin {
sourceSets {
commonMain {
dependencies {
implementation kotlin('stdlib-common')
}
}
macosMain {
}
}
}
这里的 commonMain 是固定不变的，任何项目都可以拥有全局的 commonMain 目录，在这里写平台无关的代码，同时，对应的文件夹路径必须为 src/commonMain/kotlin，这是不能个修改的，修改的结果是使得这些代码无法被编译。
如果要添加通用的依赖，可以加在 commonMain 配置内，而 macosMain 下面所配置的依赖，将只作用于 Mac 平台。无论在什么时候，commonMain 内配置的依赖都会被所有的 Target 引用，所以需要非常谨慎，有的时候引用的库不能工作在 Linux 或 Windows，那么对应的这两个平台就会报错。对于这种情况，只能把各个平台的依赖单独写开，如:
kotlin {
sourceSets {
commonMain {
... ...
}
macosMain {
dependencies {
implementation "group:name:version"
}
}
}
}
对了，还有一种依赖写法是 implementation kotlin('stdlib-common')，这是 kotlin 提供的便利，这样的代码对应的真实库是 org.jetbrains.kotlin:kotlin-stdlib-common:1.3.31，其规则为 org.jetbrains.kotlin:kotlin- 加上库的名称，加上当前所使用的 kotlin 版本号。
下面再来说 macosMain 的情况，这个名称的来源是在上面 macosX64 一句内设定的，这里可以随意修改，如:
kotlin {
macosX64("sample") {
... ...
}
sourceSets {
commonMain {
... ...
}
sampleMain {
... ...
}
}
}
在这种情况下，只要编译平台与源码内定义的名称一致，同时物理文件的目录同样改为 src/sampleMain/kotlin 即可生效。或许有的人会问，sampleMain 写着太丑了，后面的 Main 能否去掉，答案是不能，这是一种约定俗成的写法。
通常情况下，我们会将 main 函数写在 commonMain 里，以便进行统一的编译，这里大家一定发现了，在 commonMain 里，是不带 posix 库的，也就是无法引用平台的能力。所以就有人说了，Kotlin/Native 只是一套通用的语法，只能拿来写写算法，不实用啊。这里就是一种很大的误会，其实我们可以很轻易的把跨平台的东西拆开，分开写不同的代码（当然话又说回来，之前跟我学 CodeTyphon 的人都已经体会到一套 API 直接跨平台的好处了，现在分平台写代码必然不习惯，或许等后面 Kotlin/Native 拥有更多跨平台方向的包装库后，这个现象会好转，大家也可以自己造轮子）。
好了，下面来看一个实际的例子，要输出当前平台怎么做呢？Kotlin/Native 没有宏，只是依赖 gradle 来判断平台。
这里有两个全新的概念，分别是 期待 和 现实，我们可以用 expect 声明一个期待，用 actual 来声明一个现实。如下所示：
expect val platformName: String // 在 commonMain 内
fun main(args: Array<String>) {
println(platformName)
}
这里的 platformName 是一个期待，它会由 现实 的函数，在编译期来填充。
actual val platformName: String get() = "Mac" // 在 macosMain 内
actual val platformName: String get() = "Linux" // 在 linuxMain 内
编译后我们就可以看到效果了，针对不同的平台，可以打印出不同的结果。
对于任意成员，都可以用 expect 来修饰，表示它将被 actual 实现，但是要注意，一个 expect 必须在所有的 Target 内都有实现，否则编译会报错。
下面来看一个更为实际的例子，获取程序自身的全路径:
expect val exePath: String // 在 commonMain 内
fun main(args: Array<String>) {
println(exePath)
}
actual val exePath: String get() { // 在 macosMain 内
memScoped {
val length = PROC_PIDPATHINFO_MAXSIZE
val pathBuf = allocArray<ByteVar>(length)
val myPid = getpid()
val res = proc_pidpath(myPid, pathBuf, length.toUInt())
if (res < 1) throw RuntimeException("proc_pidpath failed: $res")
return pathBuf.toKString()
}
}
actual val exePath: String get() { // 在 linuxMain 内
memScoped {
val length = PATH_MAX.toULong()
val pathBuf = allocArray<ByteVar>(length.toInt())
val myPid = getpid()
val res = readlink("/proc/$myPid/exe", pathBuf, length)
if (res < 1) throw RuntimeException("/proc/$myPid/exe failed: $res")
return pathBuf.toKString()
}
}
这样就可以简单包装住各个平台不同的代码，并且给到一个统一的输出。
这里也提一下 memScoped 这种闭包的写法，在 memScoped 内，只要申请内存，在闭包结束时会自动释放，不再需要手动管理内存。
关于指针，指针可能是最让人难理解的东西了，从 C 的时代起，就有无数英雄跪倒在指针而止步不前。Kotlin/Native 一样支持指针，也尽可能的尝试让指针更容易操作。
用一个例子来解释就行了:
#include <stdio.h>
int main() {
int a[] = {1, 3, 5, 7, 9};
int* p = a;
printf("%d\n", *p);
p++;
printf("%d\n", *p);
return 0;
}
以上 C 语言代码转换成 Kotlin/Native 就是这样的:
import kotlinx.cinterop.*
fun main() {
val a = arrayOf(1, 3, 5, 7, 9)
var p = nativeHeap.allocArray<IntVar>(a.size)
for (i in a.indices) { p[i] = a[i] }
println(p.pointed.value)
p = (p + 1)!!
println(p.pointed.value)
}
关于指针，更详细的内容可以参考官方的文档(点击进入)
网友评论