Pass any Cmake build option to dependency building

[fuzhouch]

[English]
I'm building a portable Linux binary which depends on OpenAL-soft. It offers some options in CMakeLists.txt. I need to use option(ALSOFT_STATIC_LIBGCC) and option(ALSOFT_STATIC_STDCXX). However, Xrepo's xmake.lua does not have it.

I tried two approaches but none of them works:

1. Use ``xmake config --tryconfigs"-DALSOFT_STATIC_LIBGCC=ON -DALSOFT_STATIC_STDCXX=ON", but built libraries does not apply it by checking build command line.
2. Use add_requires("openal-soft 1.23.1", { alias = "openal", system = false, configs = { shared = true }, presets = { ALSOFT_STATIC_LIBGCC=true, ALSOFT_STATIC_STDCXX=true }}). It produces a warning, warning: add_requires("openal-soft 1.23.1") has unknown option: {presets=table: 0x562c694b8e20}!.

I can submit a pull request to xrepo but it should be a common needs for more packages to accept build configs.

My question is: is there any way I can pass Cmake build option to dependency building?

[中文]
Linux 下 Openal-soft 的 CMakeLists.txt 有配置选项以 option 的形式给出，比如 option(ALSOFT_STATIC_LIBGCC) 和 option(ALSOFT_STATIC_STDCXX)，但 xrepo 的编译设置 xmake.lua 里没有。我考虑过在 xrepo 的 xmake.lua 里加两个新的 config，但这个问题显然在多个库里都会遇到，一个个加就非常繁琐。

我试过两个办法，一个是 xmake config --tryconfigs="-DALSOFT_STATIC_LIBGCC=ON -DALSOFT_STATIC_STDCXX=ON"，但不起作用；第二个办法是 add_requires(... presets = {}) （官网文档提到可用于 Boost）。我加了

add_requires("openal-soft 1.23.1",    { alias = "openal", system = false, configs = { shared = true },
                                        presets = { ALSOFT_STATIC_LIBGCC=true, ALSOFT_STATIC_STDCXX=true }})

之后 xmake config 会报警告，看起来它并不认识。

warning: add_requires("openal-soft 1.23.1") has unknown option: {presets=table: 0x562c694b8e20}!

所以我的问题是：xmake 有什么通用的方法可以给 cmake 的依赖库传递额外的编译参数？

[star-hengxing]

xrepo 仓库里的包不一定能满足每个人的需求，这时就要自己手写包描述了。
简单的包可以用 set_base，复杂一点就把 xrepo 的包描述抄过来，然后用 自建包仓库

[waruqi]

，一个是 xmake config --tryconfigs="-DALSOFT_STATIC_LIBGCC=ON -DALSOFT_STATIC_STDCXX=ON"

这个是 trybuild 的配置，也不是你现在的场景使用的，它是在尝试编译没有 xmake.lua ，只要自带的 cmakelists.txt 第三方项目，xmake 会帮你快速去调用 cmake 编译它，然后你可以传递一些 Cmake的配置进去。。

[waruqi]

xmake 有什么通用的方法可以给 cmake 的依赖库传递额外的编译参数？

没有全局通用，首先不同的包邮不同的构建系统，另外这些 ALSOFT_STATIC_LIBGCC 配置，仅仅针对 openal-soft 这一个包，你全局加配置不适用。。

你想要加配置有几种方式

1. 提 pr 改进 xmake-repo 的包，加 add_configs 映射相关配置，这是最推荐的做法，一个是这样的 configs 都是配置里明文标准化定义好了，其他用户也能享受到你贡献后的这些新选项，另外 add_requires("xxx", {configs = {static_libgcc= true}}) 这样规范化配置，会非常简洁通用，即使 openal-soft 包后期换了构建系统，不使用 cmake 了，它用 meson 了，对用户也没任何影响，不会被 break。。

而你直接项目中设置 add_requires("xxx", {configs = {cmake_configs = {"-DALSOFT_STATIC_LIBGCC=ON"}}}) 这种看似更灵活的方式，有两个问题：1. 可读性很差，不够简洁，配置一多，非常乱 2. 如果上游的 openal-soft 新版本改用了 meson 或者 其他构建工具，你现有的项目就被 break 了，有一个抽象层的 configs 会更容易维护，兼容性也更好。

2. 如果你实在不想提 pr 改进 xmake-repo 里面的包，那么你也可以自建仓库，或者直接把包写到你的项目里面维护，里面配置项随意改

3. 使用 set_base 重写部分配置

[fuzhouch]

xmake 有什么通用的方法可以给 cmake 的依赖库传递额外的编译参数？

没有全局通用，首先不同的包邮不同的构建系统，另外这些 ALSOFT_STATIC_LIBGCC 配置，仅仅针对 openal-soft 这一个包，你全局加配置不适用。。

你想要加配置有几种方式

1. 提 pr 改进 xmake-repo 的包，加 add_configs 映射相关配置，这是最推荐的做法，一个是这样的 configs 都是配置里明文标准化定义好了，其他用户也能享受到你贡献后的这些新选项，另外 add_requires("xxx", {configs = {static_libgcc= true}}) 这样规范化配置，会非常简洁通用，即使 openal-soft 包后期换了构建系统，不使用 cmake 了，它用 meson 了，对用户也没任何影响，不会被 break。。

而你直接项目中设置 add_requires("xxx", {configs = {cmake_configs = {"-DALSOFT_STATIC_LIBGCC=ON"}}}) 这种看似更灵活的方式，有两个问题：1. 可读性很差，不够简洁，配置一多，非常乱 2. 如果上游的 openal-soft 新版本改用了 meson 或者 其他构建工具，你现有的项目就被 break 了，有一个抽象层的 configs 会更容易维护，兼容性也更好。

2. 如果你实在不想提 pr 改进 xmake-repo 里面的包，那么你也可以自建仓库，或者直接把包写到你的项目里面维护，里面配置项随意改

3. 使用 set_base 重写部分配置

感谢建议。其实我已经 fork 了 xrepo 的代码准备发 PR。之所以没有更新，主要是昨晚因为 openal-soft 还有别的问题：它虽然给了个静态编译的 option，但他们 CMakeLists.txt 的参数是错的，用了一堆 -W 选项但偏偏没给最重要的 -static-stdlibc++。这是他们自己的 bug，我正在联系他们询问从上游改掉 PR。这部分和 xmake 无关，而且我也不觉得应该让 xrepo 给他们打补丁（虽然我本地用 set_base() 定义的本地包已经能跑）。

其实直接传 cmake 参数主要是调试方便，最后还是要去掉的。当然，不加也可以，set_base 也能做到。

稍微扯远一点，我发现有一些配置场景并不太容易用现在的 xrepo 方式实现。还是 Hashlink 的一个依赖 mbedtls，这货虽然用 cmake 编译，但它真正的配置是要求用户在 include 目录里手工修改一个 config.h，里头用一组宏来确定各种加密签名算法哪些能支持（pcre2 也有类似的情况，很多人用默认参数就行，但我这边稍微复杂一些）。这部分我自己存了一份代码编译的，暂时没有用 xmake 管理。当然 xmake 用 lua，原则上都可以做文本替换来修改，就是会比别的库复杂很多。所以我得整理一下再提交。

[waruqi]

稍微扯远一点，我发现有一些配置场景并不太容易用现在的 xrepo 方式实现。还是 Hashlink 的一个依赖 mbedtls，这货虽然用 cmake 编译，但它真正的配置是要求用户在 include 目录里手工修改一个 config.h，里头用一组宏来确定各种加密签名算法哪些能支持（pcre2 也有类似的情况，很多人用默认参数就行，但我这边稍微复杂一些）。这部分我自己存了一份代码编译的，暂时没有用 xmake 管理。当然 xmake 用 lua，原则上都可以做文本替换来修改，就是会比别的库复杂很多。所以我得整理一下再提交。

可以定制化一个 包，在自己的 on_install 里面，调用 cmake.install 编译安装之前，通过 io.gsub/io.replace 去模式匹配替换 config.h 里面的各种配置

https://github.com/xmake-io/xmake-repo/blob/d1732bed3386d4cf004d782fa8ae65462d52a938/packages/l/libbpg/xmake.lua#L15

xmake/xmake/plugins/pack/nsis/main.lua

Line 262 in ba071b3

io.gsub(specfile, "(" .. pattern .. ")", function(_, name)

xmake-repo 里面也有不少包，会在编译之前，提前去自动修改 config.h ，可以找找参考下

[fuzhouch]

没问题。说一个好消息，我这边用自己的 local package 编译静态 libsndio 成功。目前确定是通过了 Linux 我这边 Hashlink 引擎的功能测试。代码在这边：https://github.com/fuzhouch/hashbld/blob/main/deps/packages/l/libsndio-static/xmake.lua

对我的项目来说，声音模块的静态编译就算是解决了。只要 libsndio 是静态库，那么上一层 openal-soft 也就会是静态库，最后汇总到 hashlink，整条线添加一次 -static-libgcc 和 -static-libstdc++ 就可以。Openal-soft 里的那个参数 bug 我也不用再等：那个 bug 影响的是 openal-soft 编译成动态库的场景，我已经不需要了，他们慢慢修就行。

关于 sndio package 贡献到 xrepo：我需要再读一读 sndio 的代码，把 configure 可以用的参数（rmidi，oss，umidi 一系列）都以 xrepo 参数的形式暴露出来，这样就可以发一个正式的 PR 到 xrepo。我现在的做法是 .so 一定会编译出来，只是 shared = false 才会编译一个 libsndio-static.a 的静态库，这样保证包里头的 sndiod 服务和 sndctl 工具的编译和行为完全不变，以免破坏和官方发布的兼容性。库名改了，但问题不大，反正 xmake 能根据 shared 的取值选择 -l 哪一个库。PR 应该这周就行（我本周高优先级的任务是把游戏送上线）。如果之后 sndio 团队提出不同的修改法，xmake 能替我们屏蔽这个问题（特别好评）。

另外，pcre2 和 embdtls 这两个怎么改 xrepo 的 package，方法我已经会了，不过会更慢一点，因为我现在用的 config.h 是抄 hashlink 团队的，他们定制了很多参数，得去了解下默认取值都有哪些。反正就是慢慢一个个模块摸熟悉。

感谢感谢。