关于gui计划

[e1732a364fed]

gui计划

vs_gui, 是为客户端专门编译的verysimple定制版, 该计划的原名称为vsc，意思是 vs client或者 vs cgo。

它使用gui（图形界面），编译时开启cgo，未来计划添加 tun/tap 等需要cgo编译的支持。

vs_gui只打算支持 linux amd64, linux arm64, windows_x64, windows_arm64, macos_x64, maos_appleSilicon 这六种平台架构。

编译出的文件为了方便用户识别，使用 vs_gui_ 作为前缀。

关于ui和libui

使用 https://github.com/andlabs/ui, 但是它停止更新了，而且有一些问题，我fork了一个其中的fork，在
github.com/e1732a364fed/ui

但是发现windows上编译会出错，怀疑是其中内嵌的 a 文件编译方式不对。因为这个fork是自己提供的a文件，可能编译方式不太恰当。
具体报错 是 std::__throw_bad_array_new_length

那我们自行编译一下。

首先，是跨平台的libui项目，https://github.com/andlabs/libui
但是它21年就停止更新了
更新的是这个。
https://github.com/libui-ng/libui-ng
用它编译出 a试试，发现是可以的。

编译了win64和linux_arm64的a文件，暂时未更新其他平台的a文件。mark一下以备忘。

后来编译 darwin上的a文件后，又发现遇到这个问题：
libui-ng/libui-ng#160

暂时的解决方案是按 docs/build.md 中的命令 编译它的静态库。

使用新的 libui-ng 库 和 老的 andlabs 的库 对比来说 ， 在darwin上，还是有好处的，比如entry可以快捷键复制粘贴了，multiEntry支持暗黑模式了。

整个libui唯一一个可见的问题是在windows上似乎有些卡顿，不知道原因。mac和linux上都很流畅。另外注意到的就是编译出的windows平台的静态库很大，有13MB，而其他平台上的静态库只有不到1MB左右。

andlabs/ui#184

andlabs/libui#311

使用注意事项：

github action 编译问题

之后，为了能编译，我大动干戈，修改workflow文件多次，才能在github action上成功编译；

之前用到xgo的github action，总是出错显示找不到文件位置，只好放弃xgo

结果又发现linux上编译失败，

amd上显示

# pkg-config --cflags  -- gtk+-3.0
Package gtk+-3.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-3.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-3.0' found
pkg-config: exit status 1
make: *** [Makefile_r_vsc:15: all] Error 2

而arm上显示

# runtime/cgo
gcc_arm64.S: Assembler messages:
gcc_arm64.S:28: Error: no such instruction: `stp x29,x30,[sp,'
gcc_arm64.S:32: Error: too many memory references for `mov'
gcc_arm64.S:34: Error: no such instruction: `stp x19,x20,[sp,'
gcc_arm64.S:37: Error: no such instruction: `stp x21,x22,[sp,'

等等

第一个问题，应该是没有安装 依赖包

sudo apt-get install build-essential libgtk-3-dev

第二个arm问题的话，应该是不相干的，这可能是因为，无法在linux的amd64平台上去编译arm64目标。这一点就不如macos。

在macos上可是可以这么做的。

github action太费劲，我也懒得搞了。linux上就只编译amd64版本得了～

后来又尝试使用这个： https://github.com/marketplace/actions/run-on-architecture

结果发现这个运行太慢，就尝试直接使用 gcc-aarch64-linux-gnu 作为CC, 发现这样更简单。哪用得着各种偏招哩。。

后来又发现编译时，它头文件找错位置了，先找的是amd64的头文件，导致编译再次出错

它总是找 /usr/include/x86_64-linux-gnu 这里的。这个应该是在安装 libgtk-3-dev 时安上的。用 apt remove linux-libc-dev 可以重新卸载掉。但是 libgtk-3-dev 也会被卸载掉，怎么办？

尝试暴力移除x86的include文件夹 mv /usr/include/x86_64-linux-gnu /root/后，发现会报错 很多lib找不到。这才意识到，上面安装的依赖都是 x86的依赖，而不是 arm64的。实在是 没办法继续浪费时间了，还是重新使用 run-on-architecture

编译出的 ubuntu程序使用最新的glibc，运行时提示 version GLIBC_2.32 not found, 很麻烦。编译时还是不要用 ubuntu-latest 的好。。

github action的总结的一些经验教训：

可以使用 - if: ${{ matrix.os == 'ubuntu-latest' }} 作为判断，但是必须用单引号包裹字符串； 而且也不能把这个判断放在双大括号的外面，比如这个是错误的： - if: ${{ matrix.os }} == 'ubuntu-latest'

每个step都要有唯一的id，就算if 语句给分离开了也不行

github action 只有amd64机

这种用法对于windows不好使： echo "action_state=yellow" >> $GITHUB_ENV

actions/runner#1636

有时侯github action在macos平台上产生的文件非常小，二进制格式完全是错误的，也不知道什么情况。关联 actions/upload-artifact#151
说是要用gtar而不是tar

在windows上用 tar -cJf 会导致显示 不支持xz，但是如果把这条命令放到makefile里然后再用make运行，就没问题