为 xrepo 增加更便捷指定编译器的功能

[cyfdecyf]

你在什么场景下需要该功能？

在非交叉编译的需求下，切换编译器依然是合理的需求。我能想到的切换编译器的一些场景：

• 升级项目使用的编译器
  • 对于较大的项目来说，切换到新编译器需要比较多的验证工作，因此需要同时支持两种编译器进行编译
• 不同的编译器编译期检查能力不同，多一个编译器有更多机会在编译器发现代码中的问题
• 使用其他编译器特有的功能
  • 例如 Memory Sanitizer (MSan) 只有 Clang 支持，但 Clang-13 编译速度太慢，日常还是使用 GCC

描述可能的解决方案

准备多个 Linux 环境安装不同的编译器是一个解决方案，但搭建开发环境毕竟比在现有系统多安装一个编译器工作量大很多。

目前 xrepo 指定编译器的方法：

1. 确保 package/xmake.lua 中的 on_loda 和 on_install 支持 "cross"，或者不加平台限制
2. 安装时使用 xrepo install -p cross --toolchain=<toolchain>

这个方案目前尝试可以走通，但需要修改不支持 "cross" 编译的 package。我会另外开 issue 来描述目前遇到的问题，有些问题或许并不难解决。

描述你认为的候选方案

CMake, autotools 等工具通过修改 CC, CXX 环境变量即可实现切换编译器。而目前 xrepo-cmake 的代码在调用 xmake 时特意去除了 CC, CXX 环境变量。

在 #1987 中我尝试过执行 xrepo install --toolchain 来指定编译器。
当时从直觉来说，指定 toolchain 就能切换编译器是我预期的行为。

是否可能通过在非 cross 平台下也透传 toolchain 来实现切换编译器？

之前的讨论中有说过这种方式难以对接 CI 进行测试，是否是指难以在 CI 环境中测试 toolchain 这个功能？
如果是 Ubuntu 环境的话，单个系统里安装多个编译器倒并不太麻烦。Arch Linux 上的确不太好搞，目前仅提供 Clang + GCC 两个编译器，但也能 cover 到这个 test case。

[waruqi]

关于 cross 平台

其实之前对 cross 的解释有点误解，并不是说 cross，在包构建就一定是交叉编译。你可以理解成，cross 平台时候，xmake 才会对 工具链透传所有 cc, ld, cflags 等全部工具链信息。

也就是说，你即使不是交叉编译，只是 linux 换 gcc版本，也是可以切到 cross 下，透传工具链就行了，并不强制要求一定是交叉编译工具链。

说白了，对于你这需求，唯一的区别，就是 -p linux 和 -p cross 参数的区别。。其他没有任何差异。

假设每个平台都支持工具链透传

一个包的制作，on_install("linux"), on_install("mingw"), on_install("windows") 等，都需要额外做各种工具链透传处理，参数配置变动，反而复杂化。

对包的维护，还有 xmake 内部的处理，工作量和复杂度只增不减。

如果就 cross 支持工具链透传

linux, mingw, windows 等现有已知平台的包维护，完全不用改，并且可以在 ci 上可靠验证。。

仅仅只需要加一个 on_install("cross") ，而且通常，这对包维护者，也没什么工作量，仅仅几行代码，甚至就是一个字符串的增加。。

xmake 内部会对 cmake/autoconf 等，将工具链的 cc/ld/cflags/ar 等全部信息透传过去。这跟你说的 CC 环境变量传入 cmake/autoconf 没有本质区别。。

在非交叉编译的需求下，切换编译器依然是合理的需求。我能想到的切换编译器的一些场景：

这些, cross 都支持

这个方案目前尝试可以走通，但需要修改不支持 "cross" 编译的 package。我会另外开 issue 来描述目前遇到的问题，有些问题或许并不难解决。

仅仅只是包里面加个 cross 字符串而已，其他真没啥区别了，即使让 linux 和 macosx 也支持工具链切换，其实也就是个 linux 和 cross 名字的差异。。

CMake, autotools 等工具通过修改 CC, CXX 环境变量即可实现切换编译器。而目前 xrepo-cmake 的代码在调用 xmake 时特意去除了 CC, CXX 环境变量。

cross 支持 cc cxx 完整透传，也支持 CC CXX 环境变量探测切换

是否可能通过在非 cross 平台下也透传 toolchain 来实现切换编译器？

完全不需要哈，你可以吧 linux macosx 平台的工具链切花，gcc 切到 clang 什么的，仅仅只是换个平台名字到 cross 而已。

这里只是使用 cross ，作为统一的工具链切换逻辑，而不是把工具链切换逻辑分散在不同的平台代码里面。

你可以在 linux, macosx 上，非交叉编译切 gcc-11, clang 。。不要吧 cross 理解为交叉编译，仅仅理解为：统一的工具链切换平台

xrepo install -p cross --toolchain=clang
xrepo install -p cross --toolchain=gcc-11

[waruqi]

之前的讨论中有说过这种方式难以对接 CI 进行测试，是否是指难以在 CI 环境中测试 toolchain 这个功能？

不是，现在按照包，有两种模式

1. 默认全走平台默认工具链，autoconf/cmake 内部不会去挨个透传 cc/ld/cflags 。。因为挨个透传进去，稍有差错，漏掉点什么，cmake/autoconf 就跪了。。不可靠。。

而默认工具链，ci 上会严格测试，就比如 windows，会去对 MT/MD + static/shared 各种组合编译测试，确保完全可靠，因为针对性优化过得。

也会对 mingw xcode 特殊平台工具链，内部修复解决各种对接 cmake autoconf上的坑。

而我即使让 linux/windows 等平台全加上工具链透传切换，ci 上也是没办法测试到的。。一切包的安装是否顺利，全凭用户人品，你随便换个工具链，可能就跪了。

2. 而 cross 平台，xmake 默认会对 cmake/autoconf 透传所有 cc/ld/ar 等工具链信息，整套工具链透传逻辑，也会走 ci 上针对性严格测试，确保可靠。

也就是说，即使你在 cross 平台，切换各种未知工具链，可靠性和成功率也是非常高的

[waruqi]

就拿 windows 来说

仅支持 cross 切换工具链方案

on_install("windows", function (package)
    -- 我只需要内部对接 msvc 处理包构建，而且 vs 版本还是能切换
    -- 我可以对 msvc 的各种坑，vs runtime 做特殊优化处理稳定性
    import("package.tools.cmake").install(package, configs)
end)

-- cross 处理一切工具链切换问题，透传所有，稳定测试，而通常也只需要加几行配置就行了。
on_install("cross", function (package)
    import("package.tools.cmake").install(package, configs)
end)

如果用的都是 cmake ，还可以简单合并下，仅仅多了个 cross 字符串，就全支持了。。

on_install("windows", "cross", function (package)
    import("package.tools.cmake").install(package, configs)
end)

全部平台支持切换工具链方案

我我需要根据 --toolchain 判断是否为 msvc，还是其他工具链，如果是 msvc ，内部又不能透传 cc/ld 给 cmake

而其他工具链，又要去透传他们。两种处理模式混合在一起。而ci 上，又没法测试全。

on_install("windows", function (package)
    import("package.tools.cmake").install(package, configs)
end)

也许还需要对不同工具链，加各种 包特定的配置

on_install("windows", function (package)
    if gcc then
       -- add configs
    else if msvc then
       -- add configs
    else if clang then
      -- add configs
    end
    import("package.tools.cmake").install(package, configs)
end)

这还只是 windows，linux, macosx 都要来一遍。。

而不是像方案一，统一放在 on_install("cross") 里面处理它们，windows 平台专心搞 msvc

[waruqi]

确保 package/xmake.lua 中的 on_loda 和 on_install 支持 "cross"，或者不加平台限制

如果这个包全平台支持，也支持工具链透传，只需要这么配置 on_install(function(package)) ，原本就是可以不限制的

如果这个包，切换其他工具链，原本就不支持，比如用的 makefile ，不是 autoconf/cmake，并且 makefile 内部也没获取 CC 变量，压根支持不了。。

你不限制，用户切工具链安装，报一堆编译错误，还不如直接提示不支持，省得用户趟坑。

如果这个包后续想通过 patch makefile 进行工具量切换支持了，只需要在 on_install("cross") 里面，统一处理各种 patch 逻辑。。其他平台的构建脚本，基本不会干扰，维护性和可扩展性，反而是更好的，而且 ci 上还能测试到 patch makefile 后，工具链切换的可用性

[cyfdecyf]

非常感谢如此详细的解释。我日常只使用 gcc, clang 这两个编译器，对于 msvc, mingw 以及 windows 上的编译没有经验。我能想像得到支持多种编译器可能遇到很多问题，完全接受按现在的方案进行处理。

仔细想了下，描述下我的理解，烦请指出有错的地方。

简单起见，以下对 platform, toolchain 的理解描述不考虑交叉编译。

package 能否在特定 platform 上编译、能否使用特定 toolchain，这是 package 源代码以及其构建代码本身的问题。

任何一次编译构建都在一个特定的 platform 和 toolchain 的组合下进行。如果仅指定 platform，实际隐含了使用该 platform 默认的 toolchain。

• 每个 platform 默认使用哪种 toolchain 还是比较固定的，所以目前设计相比指定 toolchain 再细分 platform 更加合理
• 我们在写 on_install("linux") 这样平台特殊的处理逻辑时，其实也假定了所使用的编译器

cross 是一个特殊 platform，这个 platform 会透传 toolchain 以及所有 cflags 等工具链相关的参数。

• 这个 platform 就是设计用来切换工具链，实际编译使用的操作系统由编译时所在的系统决定

问题 1： 那在 on_install("cross") 中，如何再区分当前编译的系统的 platform?

具体来说，是否可以写如下代码：

on_install("cross", function (package)
    if package:is_plat("windows") then
        -- add configs
    end
end)

问题 2： 在卸载 gcc, clang 的 Arch Linux 上观察了下 xrepo install (不指定 -p 也不指定 --toolchain) 的行为，看到有 checking gcc，然后 checking clang，看来 xmake 检测了系统上的编译工具。好奇此处检测编译器的行为是否仅是作为环境检查而进行？

[waruqi]

问题 1： 那在 on_install("cross") 中，如何再区分当前编译的系统的 platform?

目前的处理逻辑，这里面再去判断原生 windows/linux 平台去区分不了的，因为已经切到 -p cross 了。。

但是，也不是完全没有办法区分，因为除了，linux, macosx, windows等已知的内置平台，其他任意未知平台，都会做为 cross 逻辑处理，所以你可以用一个其他平台名区分它，比如：

xrepo install -p xxx_windows
xrepo install -p xxx_linux

然后，就能判断了

on_install("cross", function (package)
    if package:is_plat("xxx_windows") then
        -- add configs
    end
end)

这样也避免了，windows 等内置平台内部的工具链和特殊逻辑干扰。

问题 2： 在卸载 gcc, clang 的 Arch Linux 上观察了下 xrepo install (不指定 -p 也不指定 --toolchain) 的行为，看到有 checking gcc，然后 checking clang，看来 xmake 检测了系统上的编译工具。好奇此处检测编译器的行为是否仅是作为环境检查而进行？

这是因为，每个内置平台，默认都会绑定一批工具链，比如 linux ，会自动尝试从 gcc/ clang 探测，优先使用。

不同平台探测的工具链名，顺序都有差异。

比如：macosx 下，clang 会优先探测，windows 下 msvc 会优先探测等等

[cyfdecyf]

切换到 "cross" 之后，原先针对 platform 特定的配置就不生效了。对于同平台切换编译器来说，除了在 on_load, on_install 上添加 "cross" 以外，还需要在针对当前 platform 特殊处理的代码上对 "cross" 也加上相同的处理逻辑。

举例来说，xrepo gflags 在针对特定平台来添加线程库的链接，这部份代码在 -p cross 时不会执行到。

[waruqi]

其实很多包的特定平台处理，也是依赖平台默认工具链的，比如 windows 平台的大部分特殊处理，都是假定在 msvc 下的 vs runtime 处理一样，工具链一变，这些特定的平台设置，有些可能还是需要，但有些已经不能默认设置上了。。

而市面上工具链繁杂，gcc, clang，各种嵌入式编译器，交叉工具链等等，哪些工具链需要默认开哪些配置，在包里面是没法完美处理全的。。

尽管 gflags 目前的这个 mt 设置，也许通吃所有工具链，仅跟平台相关。。但是其他包就说不准了。。

所以，你如果切了工具链，建议每次手动指定全 是否开启 哪些配置，不要依赖包的默认配置值。。xrepo install -p cross --toolchain=clang -f "mt=true" gflags

[cyfdecyf]

我只是想说明，目前通过 "cross" 能达到换编译器的目的，但除了 on_install, on_load 之外，还需要有其他地方进行修改。

切换编译器并不是我的日常需求，只是处于 g++-4.8 到更新版本 g++ 涉及 ABI 变化的问题才对此有比较强的需求。不过我可以考虑 setup 新的开发环境来切换编译器，而不是在同一台机器上切。

关于 gflags 的问题再补充一下：

gflags 的问题是 on_test 链接时会出错，之前 PR 里的写法导致切到 "cross" 之后无论是否添加 -f mt=true 都不会把 syslink 添加进去。

gflags 库本身存在问题，它的 pkgconfig 文件 --libs 有 pthread，但 cmake module 文件里没有。所以通过 cmake 使用 gflags 的用户就得自己增加 pthread 的链接选项。

这里我想了解下 on_test 通过哪种机制去获取 link 参数？（之前跟代码看到了 xmake check_cxsnipet 等函数，但没深入了解。）

像这种库本身存在问题，包管理工具将各种安装过程中的 patch, hack 通过代码记录下来，避免大家重复劳动，这是包管理工具能提供的很大的价值。

[waruqi]

判断下，如果是 is_plat("cross") ，也加上 pthread syslinks 就可以了。。不管是交叉工具链，还是gcc/clang 本地工具链，都是需要 pthread 的。

不过对其他平台的 toolchain 切换，我也实验性加上了，不过目前没法做 ci 测试，不一定对每个包都可靠。#2117

[cyfdecyf]

我昨天已经通过改 private repo 里 gflags xmake.lua 的方式搞定了。xrepo 能很方便的用 private repo，所以只要用户愿意改代码，此类问题还是挺好解决的。

[cyfdecyf]

这个 commit 为 gflags 和 glog 添加了 "cross" platform，能正常使用。

昨天我在 Arch Linux 上指定 -p cross --toolchain=clang-13 遇到的编译错误是因为 pacman::clang 只提供的了 clang++ 而没有 clang++-13，导致链接错误。创建一个 clang++-13 的软链即可解决。

这个用法对 package xmake.lua 文件的改动很少，创建一个 private xrepo repository 也不困难，从完成指定编译器的目的来说足够了。

还有一些问题想做探讨。

关于 xrepo 的 package：

1. 我是否应该将这个改动提交 PR 给 xmake-repo？
2. 在创建 xmake repo 的包时，什么时候不应该添加 "cross"？
   • 如果从支持切换编译器的角度来看，似乎总是应该加上 "cross"

关于 xmake 的行为：

对于仅指定 --toolchain 未指定 -p cross 的用法，我们是否可以从以下两种行为中选择一种：

1. 报错，告诉用户未指定 -p cross 时 --toolchain 参数无效
2. 自动加上 -p cross 参数，并警告用户 platform 相关的设置会不生效
   • 目前 xrepo-cmake 中的行为是在指定 toolchain 时会默认加上 -p cross

[waruqi]

我是否应该将这个改动提交 PR 给 xmake-repo？

如果这些包，可以支持上 cross，欢迎来 pr 。。之前有些包 我只是没空弄和测试，所以暂时没加而已

在创建 xmake repo 的包时，什么时候不应该添加 "cross"？

1. 包自身源码不支持其他工具链，比如交叉编译工具链等等，或者切到其他工具链，ci 编译器暂时通不过
2. 构建工具不支持，比如 硬编码的makefile，这种，需要对 makefile 打 patch，透传 cc，或者干脆走 xmake port ，如果短期人力不够，我一般会暂时禁用搁置

报错，告诉用户未指定 -p cross 时 --toolchain 参数无效
自动加上 -p cross 参数，并警告用户 platform 相关的设置会不生效
目前 xrepo-cmake 中的行为是在指定 toolchain 时会默认加上 -p cross

最好是直接报错提示。

[waruqi]

另外，如果指定了 toolchain，我昨天改进了下，对 buildhash 也增加了 toolchain 的计算，不同工具链安装的包，不会互相冲突。

[waruqi]

这个，我转入 discussion 了，回头可以继续在那边讨论。

[cyfdecyf]

xrepo remove 可能要加入对 toolchains 的支持。当然目前可以通过手工删除的方式来解决。

$ xrepo scan libunwind
scanning packages ..
libunwind-v1.6.2:
  -> ee651f42c30745f6abc414c060337018: linux, x86_64, unused
    -> {debug=false,minidebuginfo=true,pic=true,shared=false,zlibdebuginfo=true}
  -> a8242ea273e54d9284d4a8fe7320c29c: cross, none
    -> {debug=false,minidebuginfo=false,pic=true,shared=false,toolchains="clang",zlibdebuginfo=false}

$ xrepo remove -p cross -f debug=false,minidebuginfo=false,pic=true,shared=false,toolchains=clang,zlibdebuginfo=false libunwind
error: checking for architecture ... none
error: target(working): toolchain not found!

$ xrepo remove -p cross --toolchains=clang -f debug=false,minidebuginfo=false,pic=true,shared=false,toolchains=clang,zlibdebuginfo=false libunwind
error: Invalid option: --toolchain=clang

[waruqi]

嗯 回头我看下，你可以单开个feature request

[cyfdecyf]

#2109 昨天开的 feature request 已经实现，赞速度，谢谢~