希望add_deps支持仅继承设置，不影响编译顺序

[Dozingfiretruck]

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

希望add_deps支持仅继承设置，比如包含头文件目录，但是这些并不需要设置编译顺序，所以两个taget可以循环依赖
就像cmake的
target_link_libraries(A PUBLIC B)
target_link_libraries(B PUBLIC A)

描述可能的解决方案

希望add_deps支持仅继承设置，不影响编译顺序

描述你认为的候选方案

No response

其他信息

No response

[Issues-translate-bot]

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

---

Title: I hope add_deps supports only inheriting settings and does not affect the compilation order.

In what scenario do you need this function?

I hope add_deps supports only inheriting settings, such as including header file directories, but these do not need to set the compilation order, so the two target can be cyclically dependent.
Just like cmake
target_link_libraries(A PUBLIC B)
target_link_libraries(B PUBLIC A)

Describe possible solutions

It is hoped that add_deps supports only inheriting settings and does not affect the compilation order.

Describe your alternatives

No response

Other information

No response

[waruqi]

希望add_deps支持仅继承设置，不影响编译顺序

关键是继承了设置，就有可能依赖顺序，

A, B 两个库，禁用构建顺序，仅仅继承了public defines 和 links 等设置，那么构建 A 的时候，就会带上 -lB

而 A.add_deps("B", {order = false})，又禁用了编译顺序，导致先构建 A 时，找不到 -lB 导致编译出错。

除非还得额外禁用 B 的 links 默认自动导出，这又跟仅仅继承设置冲突，还得做更细粒度的配置，这会导致很多的混乱，用户更搞不清楚 add_deps 的用法了。

[waruqi]

尽管禁用 order 本身实现不复杂，但我试了下，似乎会引入很多的边缘 case 导致各种其他问题。

如果依赖层级过深，从深层次 deps 继承过来的 一些 public 设置，比如 links，也可能存在构建顺序间的依赖，只是用户没发现，后续导致链接问题，还得查半天。

[waruqi]

除非是 A.add_deps("B", {inheirt = false, order = false}) 搭配使用，连配置继承也禁了，但这个用法也太复杂了，而且约束性太多。

[Issues-translate-bot]

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

---

I hope add_deps supports only inheriting settings and does not affect the compilation order.

The key is that if settings are inherited, it may depend on the order.

Two libraries, A and B, disable the build order and only inherit the links setting. Then when building A, -lB will be used.

And A.add_deps("B", {order = false}) disables the compilation order. As a result, when A is built first, -lB cannot be found, causing compilation errors.

[Issues-translate-bot]

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

---

Although disabling order itself is not complicated to implement, I tried it and it seems that it will introduce a lot of edge cases and cause various other problems.

If the dependency level is too deep, some public settings inherited from deep-level deps, such as links, may also have dependencies between build sequences, but the user does not discover them, which will lead to link problems and will take a long time to investigate.

[Issues-translate-bot]

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

---

Unless used in conjunction with A.add_deps("B", {inheirt = false, order = false}), even configuration inheritance is disabled, but this usage is too complicated and too restrictive.

[waruqi]

这里有个实验性 patch #6948

但禁用顺序在继承配置上，会出现很多隐患，如果不行，就不考虑支持了。

如果只是为了多个 targets 联编，建议还是走 xmake build -g group + set_group 来实现

[Dozingfiretruck]

希望add_deps支持仅继承设置，不影响编译顺序

关键是继承了设置，就有可能依赖顺序，

A, B 两个库，禁用构建顺序，仅仅继承了public defines 和 links 等设置，那么构建 A 的时候，就会带上 -lB

而 A.add_deps("B", {order = false})，又禁用了编译顺序，导致先构建 A 时，找不到 -lB 导致编译出错。

除非还得额外禁用 B 的 links 默认自动导出，这又跟仅仅继承设置冲突，还得做更细粒度的配置，这会导致很多的混乱，用户更搞不清楚 add_deps 的用法了。

只要能够和cmake的target_link_libraries行为一致就好了

[Issues-translate-bot]

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

---

I hope add_deps supports only inheriting settings and does not affect the compilation order.

The key is that if settings are inherited, it may depend on the order.

Two libraries A and B disable the build order and only inherit settings such as public defines and links. Then when building A, -lB will be used

And A.add_deps("B", {order = false}) also disables the compilation order. As a result, when A is built first, -lB cannot be found, causing a compilation error.

Unless you have to additionally disable the automatic export of B's ​​links by default, which conflicts with just inheriting the settings, you have to do more fine-grained configuration, which will cause a lot of confusion, and users will not be able to figure out the usage of add_deps.

As long as the behavior is consistent with cmake's target_link_libraries, it will be fine

[Dozingfiretruck]

这里有个实验性 patch #6948

但禁用顺序在继承配置上，会出现很多隐患，如果不行，就不考虑支持了。

如果只是为了多个 targets 联编，建议还是走 xmake build -g group + set_group 来实现

是为了继承比如头文件等配置并且不影响编译顺序

[Issues-translate-bot]

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

---

There is an experimental patch #6948

However, there will be many hidden dangers in the inheritance configuration of the disabling order. If it does not work, support will not be considered.

If it is just for building multiple targets, it is recommended to use xmake build -g group + set_group to achieve it

It is to inherit configurations such as header files and not affect the compilation order.

[waruqi]

这里有个实验性 patch #6948
但禁用顺序在继承配置上，会出现很多隐患，如果不行，就不考虑支持了。
如果只是为了多个 targets 联编，建议还是走 xmake build -g group + set_group 来实现

是为了继承比如头文件等配置并且不影响编译顺序

但是你 add_deps 了 library target ，默认还是会继承 links，导致找不到 links 失败。