为其他常用 Linux 发行版多做考虑

[WhiredPlanck]

最近偶然看到了 xmake 这个工具，觉得还不错。

我是 Arch Linux / NixOS 用户，和两个发行版的 dev 们讨论过打包 xmake 的事情。总体讨论的评价是，xmake 有点“总是假设用户在用 Cent OS 7”，有不少不利于像 Arch Linux、NixOS 等日渐走入众 Linux 用户的发行版打包的点。NixOS 的打包请求最后还是自行关闭了。

主要为：

• 过于强调内置。作为软件上游绑定一堆依赖确实是常见做法（且 xmake 的定位有此做法也完全没问题），但是常见发行版（Cent OS 7 真的是昔日黄花了，不在此列）会习惯用他们自己提供的依赖（包），dev 们发现 xmake 很难使用外置依赖，或者使用了 fork 过的依赖，由于不清楚具体修改了什么，因此不敢随意替换 [1]。此外还有一些循环依赖问题（对象是 tbox）[2]。没有依赖有时候往往是最大的劣势 [3]。期望能模块化一点。
• 一些不必要或者非最佳实践的 hack。比如类似

  xmake/core/makefile

  Line 280 in 612f1a2

  base_LIBNAMES += $(shell if { cat detect/curses.c | $(CC) -xc - -lcurses -ltinfo -o /dev/null 2>/dev/null; }; then echo curses tinfo; fi )

  这样的检测，有且应该交由现成的工具 —— 比如 autoconf 这类 —— 来做 [4] [5]。

在我看来 xmake 是个我愿意推广的工具，但综上所述，xmake 的实际情况可能不利于某些推广方向/渠道。期望能多有相关考虑。

[waruqi]

xmake 有点“总是假设用户在用 Cent OS 7”

好吧，其实我都没怎么用过 centos 。。

过于强调内置。作为软件上游绑定一堆依赖确实是常见做法（且 xmake 的定位有此做法也完全没问题），但是常见发行版（Cent OS 7 真的是昔日黄花了，不在此列）会习惯用他们自己提供的依赖（包），dev 们发现 xmake 很难使用外置依赖，或者使用了 fork 过的依赖，由于不清楚具体修改了什么，因此不敢随意替换

基本没做任何修改，用 fork 仅仅只是为了 submodules 化，方便 git submodules 管理，固定到某个特定的 commit 而已，通常我不会去改第三方依赖的任何代码。

此外还有一些循环依赖问题（对象是 tbox）

tbox 是基础库，不跟 xmake 强相关，也不是仅仅 xmake 需要它，它本身肯定需要用 xmake 来维护的，不能因为 xmake 用到了它，就强行把 tbox 改用其他构建工具来维护。

但是不存在构建的循环依赖，在构建 xmake 时候用的是 makefile ，构建 tbox 也是用 xmake 里面的 makefile 来编译。

如果要单独编译安装它，不依赖 xmake，也可以用外置的 makefile/cmakelists 来实现编译（比如提前用 xmake project -k cmake 生成 cmakelists），我之前也尝试过打包 debian ，用了外置的 cmakelists 去维护 tbox 构建。。参考：https://salsa.debian.org/xmake-team/tbox/-/blob/master/debian/CMakeLists.txt

没有依赖有时候往往是最大的劣势

对于打包进发行版，我也知道有这个问题，但是目前这边还是优先考虑无依赖编译安装，毕竟不进发行版，也还是可以用 xmake，99% 的情况下，用户都能省去折腾依赖的安装问题，为了进发行版，把编译安装整的过于复杂 得不偿失。

当然，我也考虑过这个问题，所以 makefile 也会去优先探测系统上已经安装的 第三方依赖库，不是强制内置依赖的，如果系统上已经安装了 libsv, lua curses等依赖，也会直接使用，现在也是完全支持的。

一些不必要或者非最佳实践的 hack。比如类似 autoconf

不想引入 autoconf 这种依赖，然后项目根目录充斥了一堆的乱七八糟的脚本和配置文件。

尽管我也很想进发行版，但我也不会为了进去，把项目自身编译搞的过于复杂，并且根目录下充斥各种其他的autoconf脚本。

另外，我看 cmake 也是自己搞了一套 hack 的东西去各种 check ，https://gitlab.kitware.com/cmake/cmake/-/blob/master/bootstrap 也并没有用 autoconf

[waruqi]

lcurses 好像确实比较飘忽，我见到 GitHub 上有好多仓库

都不是，是从 https://sourceforge.net/p/lua-cui/code/HEAD/tree/trunk/lua_cui/src/lcurses.c 上提取的单独文件，还是07年的一个项目，github上应该不会有，实在不行可以先禁用这个，问题应该不大，不是必选依赖。

不过另外你提到了 xmake 依赖了 tbox，但 tbox 又靠 xmake 构建，这一般是怎么处理的呢？

tbox 项目单独编译用的是 xmake，但是目前 xmake 源码内置的 tbox submodules 是用的 xmake 里面的 core/src/tbox/makefile 来编译的，并没有用 xmake

如果要单独整合进去，也可以用 https://salsa.debian.org/xmake-team/tbox/-/blob/master/debian/CMakeLists.txt 切到 cmake 来编译

[waruqi]

https://github.com/luaposix/luaposix

跟这个没啥关系，用这个，那我还不如彻底重写遍 lcurses 了，也就一个代码文件

[WhiredPlanck]

了解，感谢解答。

[waruqi]

lcurses 我基本重写过了，就没这个外部依赖了，

[waruqi]

我打算彻底删了 luajit 了，也已经好久没用到了。 #3117

[waruqi]

搞了个轻量版的 xmake ，配置API跟 xmake 保持一致，纯shell脚本实现，无任何依赖，也不需要安装，只需要复制 configure 脚本到工程根目录即可使用

后面我打算用这个重构替代 xmake 自身源码 makefile 构建，替代 makefile 做到更好的依赖检测，类似 autoconf。
https://github.com/xmake-io/xmake.sh

[waruqi]

tbox 我已经用 xmake.sh port 好了，https://github.com/tboox/tbox/pull/201/files

无任何安装，直接 ./configure; make 就能编译

后面再把 xmake port 掉就行了

[waruqi]

xmake 源码现在也完全用 xmake.sh port 好了，下个版本初步可用，在下个版本，会把老的 makefile 去掉。。https://github.com/xmake-io/xmake/blob/master/configure

[waruqi]

老的 makefiles 我全部删了，现在干净了，全走新的 ./configure #3200

[waruqi]

arch 官方仓库已经进去了。。

[WhiredPlanck]

今天在开源中国上看到了 Xmake 新版发布的消息，感谢作者对开源事业的辛勤付出 ～

[wineee]

我在尝试为 NixOS 打包 xmake, 暂时先放在 nur 了，等完善后再向 nixpkgs 提交， wineee/nur-packages@fc4497b

目前主要有 3个问题：

1. 在使用 xmake.sh 编译 xmake 时，我希望开启 external 选项使用系统库，但是尝试了 --external=true --external=yes 都无法生效，只能强行 patch 源码，我将 option 的默认值改成 true 也没有生效，暂时是这样处理的

 # add projects
-if ! has_config "external"; then
+if false; then
     if is_config "runtime" "luajit"; then
         includes "src/luajit"

2. xmake 似乎可以使用 pkg-config 寻找 tbox，但是我打包的 tbox 没有提供 .pc 文件
   https://github.com/xmake-io/xmake/blob/master/core/xmake.sh#L189-L203

希望 tbox 可以提供 .pc 文件
另外 tbox 提供的是静态链接库，能否改为提供动态链接库

3. xmake-core-sv 的 tag 太老了，无法编译，需要打一个新的 tag

[waruqi]

但是尝试了 --external=true --external=yes 都无法生效

./configure --external=y
make

xmake 似乎可以使用 pkg-config 寻找 tbox，但是我打包的 tbox 没有提供 .pc 文件

目前走 xmake 安装是会导出 pc，但是走 xmake.sh 编译暂时还不支持导出。。你可以打个 patch ，直接生成一个 pc

另外 tbox 提供的是静态链接库，能否改为提供动态链接库

不支持

xmake-core-sv 的 tag 太老了，无法编译，需要打一个新的 tag

不老 就是最新的 commit ，用 xmake-core 分支。https://github.com/xmake-io/xmake-core-sv

[wineee]

1. 使用 --external=y 同样无效

> configure flags: --prefix=/nix/store/bpygdjfcbypm1x1vh69llwga9ykbsc60-xmake-2.7.9 --external=y
> ./configure: .: line 778: can't open '/build/source/core/src/tbox/tbox/src/xmake.sh': No such file or directory

2. xmake-core-sv 的最新 commit 是可以用的，只是希望更新一下 tag，最新的 tag v1.0 是 17 年的
3. 我尝试使用 xmake 编译 tbox，只是默认参数没有提供 .pc 文件， xmake 安装是导出 pc 是其他机制（xrepo？）生成的吗

[waruqi]

xmake-core-sv 的最新 commit 是可以用的，只是希望更新一下 tag，最新的 tag v1.0 是 17 年的

更新了，只能更新到 v1.1 ，上游代码只有这一个新 tag，除非让上游更新加 tag

我尝试使用 xmake 编译 tbox，只是默认参数没有提供 .pc 文件， xmake 安装是导出 pc 是其他机制（xrepo？）生成的吗

走安装 xmake install -o xxx 才会生成。

使用 --external=y 同样无效

我这里测试可以，设置后，跳过了内部 tbox 源码编译

ruki-2:xmake ruki$ ./configure --external=y
checking for platform ... macosx
checking for architecture ... x86_64
checking for make ... ok
checking for the c compiler (cc) ... clang
checking for the c++ compiler (cxx) ... clang
checking for the assembler (as) ... clang
checking for the objc compiler (mm) ... clang
checking for the objc++ compiler (mxx) ... clang
checking for the linker (ld) ... clang++
checking for the static library archiver (ar) ... ar
checking for the shared library linker (sh) ... clang++
checking for toolchain ... clang
checking for readline .. ok
checking for curses .. ok
checking for atomic .. no
checking for lua .. no
checking for luajit .. ok
checking for lz4 .. ok
checking for sv .. no
checking for tbox .. no
checking for wchar .. no
analyzing project configuration ..
generating build/macosx/x86_64/release/xmake.config.h ..
build/macosx/x86_64/release/xmake.config.h is generated!
generating makefile ..
makefile is generated!
ruki-2:xmake ruki$ make
compiling.release core/src/xmake/xmake.c

[wineee]

因为我打算使用系统库编译，没有下载 submodule 的源码，当我初始化 submodule 后，确实可以正常编译并且没有使用 内部 tbox 源码

但是既然没编译内部 tbox 源码， 按说 src/tbox/tbox/src/xmake.sh 不存在应该也可以编译，但实际上不行，你可以尝试删除 src/tbox/tbox 处的源码，应该可以复现

我怀疑是这一行有问题：
https://github.com/xmake-io/xmake/blob/992cc3c22e49a7a7f8a47d6b10d34af0128c58af/core/xmake.sh#LL207

if ! has_config "external"; then
    if is_config "runtime" "luajit"; then
        includes "src/luajit"
    else
        includes "src/lua"
    fi
    includes "src/lua-cjson"
    includes "src/lz4"
    includes "src/sv"
    includes "src/tbox"
fi

不太熟悉 shell, 如果我反着来，改成 if has_config "external"; ， 然后使用 ./configure --external=n， 是能正常工作的，这里用 ！ 判否是否有点问题

[waruqi]

--external=y 只是用来禁用内部源码编译，但是你还是需要拉取完整代码的额，避免不了，xmake.sh 有两次加载过程，首次加载 options 。。这个时候 configs 还没初始化，无法判断，但是所有子 xmake.sh 还是需要加载的。。

但这不影响后续你使用外部库，你只要完整拉取源码就行了。。不要走 git 。

用 https://github.com/xmake-io/xmake/releases/download/v2.7.9/xmake-v2.7.9.tar.gz

里面带了所有 submodules 代码，并且去掉了无关的 tests 等目录。。安装包尽量用 tar 包。。brew/pacman/debian 包目前都基于 tar 包，而不是自己拉 git