大型项目用 xmake 构建的最佳实践？

[TOMO-CAT]

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

如果我需要在一个大型项目中编译 static/shared 库，需要有很多中间小 target（非库类型），要对每个子文件的编译选项单独控制，最终汇总成库文件，有对应的项目参考吗？

目前我的写法都是在根目录写一个 xmake.lua 编译一个项目的产出库，希望可以将项目中的一部分源码文件单独编译成一个 target，最后再汇总成一个静态库/动态库。

我尝试过将子 target 定义成 static 后面设置 set_policy("build.merge_archive", true) 汇总成一个总的 static target 会出现静态库丢失的问题，翻看 issue 好像是会将已经 merge 的 static target 吞掉，这样就无法被多个其他 target merge。

描述可能的解决方案

希望大型项目中 xmake 有一种使用方式类似于 blade/bazel build //path/to/folder:target，可以拆分成多份 xmake.lua 文件。

描述你认为的候选方案

我尝试过 object target，但是不改动源码的情况下，其他 object target add_deps 这个 object target 时好像不会自动传递依赖关系。

其他信息

No response

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Title: What are the best practices for building large projects with xmake?

In what scenario do you need this function?

If I need to compile a static/shared library in a large project, I need to have many intermediate small targets (non-library types). I need to control the compilation options of each sub-file individually and finally summarize them into a library file. Is there a corresponding project reference?

At present, my writing method is to write an xmake.lua in the root directory to compile the output library of a project. I hope that part of the source code files in the project can be separately compiled into a target, and finally summarized into a static library/dynamic library.

I have tried defining the sub-targets as static and then setting set_policy("build.merge_archive", true) to combine them into a total static target. There will be a problem of static library loss. Looking at the issue, it seems that the static targets that have been merged will be swallowed up. , so that it cannot be merged by multiple other targets.

Describe possible solutions

I hope that in large projects, xmake can be used in a way similar to blade/bazel build //path/to/folder:target, which can be split into multiple xmake.lua files.

Describe your alternatives

I tried object target, but without changing the source code, other object targets do not seem to automatically transfer dependencies when adding_deps to this object target.

other information

No response

[waruqi]

一种走 多个 static target ，最后 link 成一个 shared target
或者走 set_kind object，它只合并 objects
或者直接 add_files 粒度配置，add_files("src/*.c", {defines = "XXX", cxflags = "-Dxxx"})

[TOMO-CAT]

一种走 多个 static target ，最后 link 成一个 shared target 或者走 set_kind object，它只合并 objects 或者直接 add_files 粒度配置，add_files("src/*.c", {defines = "XXX", cxflags = "-Dxxx"})

第一种方式对静态库项目不太友好，如果一个 target 没有任何源文件的话无法添加其他的 static target。另外我们现在依赖 xmake install 工具，需要对每个不导出的 target 都配置 set_default(false)，一旦漏了就会导出到成品库。

第三种方式对于 add_syslinks 和 add_packages 隔离性不太好，后续删掉对应的 源码文件时无法和它对应的 links 和 packages 对应上。而且就我们当前的项目而言会导致这个 target 的描述过于复杂。

---

我个人偏向第二种方式，但是一个 object target add_deps 另一个 object target 时不会自动合并 objects。我感觉这一块稍微改一下源码应该能实现。不过还是一个比较妥协的操作，请问一下现在企业的大型项目接入 xmake 是如何处理这个问题的。我感觉最佳方案还是出一种新的 target kind，add_deps 时自动继承 package 和 links 以及对应的产出物。不知道这个功能有在 xmake 未来的发展计划里吗？

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

One way is to use multiple static targets, and finally link to a shared target or use set_kind object, which only merges objects or directly add_files granular configuration, add_files("src/*.c", {defines = "XXX", cxflags = "-Dxxx"})

The first method is not very friendly to static library projects. If a target does not have any source files, other static targets cannot be added. In addition, we now rely on the xmake install tool. We need to configure set_default(false) for each target that is not exported. Once it is missed, it will be exported to the finished product library.

The third method is not very good for the isolation of add_syslinks and add_packages. When the corresponding source code file is subsequently deleted, it cannot correspond to its corresponding links and packages. And for our current project, the description of this target will be too complicated.

---

I personally prefer the second approach, but objects will not be automatically merged when one object target add_deps another object target. I feel that this can be achieved by slightly changing the source code. However, it is still a relatively compromised operation. I would like to ask how the large-scale enterprise projects are now connected to xmake to deal with this problem. I think the best solution is to create a new target kind that automatically inherits package and links and corresponding outputs when adding_deps. I wonder if this feature is included in xmake’s future development plans?

[waruqi]

不考虑新增 kind ，目前 add_deps 原本就会 继承 package 和 links 。其他的所有需求，自己走 rules 实现。或者直接 描述域 function 去 wrap 下，按需添加到 target

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Regardless of the new kind, currently add_deps will inherit package and links. All other requirements can be implemented by following the rules yourself.

[TOMO-CAT]

不考虑新增 kind ，目前 add_deps 原本就会 继承 package 和 links 。其他的所有需求，自己走 rules 实现。或者直接 描述域 function 去 wrap 下，按需添加到 target

rules 怎么继承 object target 产出的 ,o 文件呢，在 after_build 阶段写脚本往 target:objectfiles 里添加依赖的另一个 object target 的所有 objectfiles 吗？有项目是这么操作的吗参考下

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Regardless of the new kind, currently add_deps will inherit package and links. All other requirements can be implemented by following the rules yourself. Or directly describe the domain function under wrap and add it to the target as needed

How to inherit the ,o files produced by the rules object target? In the after_build stage, write a script to add all the objectfiles of another object target that depend on target:objectfiles? Is there any project that operates like this? Please refer to it.

[waruqi]

不考虑新增 kind ，目前 add_deps 原本就会 继承 package 和 links 。其他的所有需求，自己走 rules 实现。或者直接 描述域 function 去 wrap 下，按需添加到 target

rules 怎么继承 object target 产出的 ,o 文件呢，在 after_build 阶段写脚本往 target:objectfiles 里添加依赖的另一个 object target 的所有 objectfiles 吗？有项目是这么操作的吗参考下

.o 走 add_deps 不就好了么，其他配置走 add_rules

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Regardless of the new kind, currently add_deps will inherit package and links. All other requirements can be implemented by following the rules yourself. Or directly describe the domain function under wrap and add it to the target as needed

How to inherit the ,o files produced by object target? In the after_build stage, write a script to add all the objectfiles of another object target that depend on target:objectfiles? Is there any project that operates like this? Please refer to it.

Wouldn't it be better to use add_deps for .o, and add_rules for other configurations?