Skip to content

Commit 64d9bd3

Browse files
committed
update titles
1 parent 3bdaad4 commit 64d9bd3

File tree

2 files changed

+8
-6
lines changed

2 files changed

+8
-6
lines changed

docs/api/description/global-interfaces.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,8 @@ target("test")
4949
add_files("src/*.c")
5050
```
5151

52+
#### Add helper configurations {add-helper-configurations}
53+
5254
Above v2.8.5 can includes include some built-in helper configuration scripts, e.g.:
5355

5456
```lua
@@ -79,7 +81,7 @@ only introduces the helper scripts related to check_cfuncs in the check director
7981

8082
With `@builtin` we can distinguish between the files in the current user's project directory and the built-in files in the xmake installation directory.
8183

82-
#### Scope Description
84+
#### Scope Description {#scope-description}
8385

8486
Configurations introduced by `includes` inherit and take effect in a tree-like hierarchy. That is, global configurations in the current `xmake.lua` file will apply to all `includes` sub-xmake.lua files. For example:
8587

@@ -106,7 +108,7 @@ For example, if the imported `foo/xmake.lua` contains a global `add_defines` con
106108
This scope isolation can avoid many hidden configuration conflicts and scope pollution. In highly nested project configurations, implicit global imports can cause many problems.
107109
:::
108110

109-
#### Modular and Reusable Configurations
111+
#### Modular and Reusable Configurations {#modular-reusable}
110112

111113
So, if I want to modularize and reuse configurations, how should I do it? Simply encapsulate the configurations you want to reuse within a function, for example:
112114

docs/zh/api/description/global-interfaces.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ target("test")
3737
add_files("src/*.c")
3838
```
3939

40-
#### 递归引入子配置
40+
#### 递归引入子配置 {#recursively-add-configurations}
4141

4242
我们也可以通过模式匹配的方式,递归添加多个工程子目录文件:
4343

@@ -49,7 +49,7 @@ target("test")
4949
add_files("src/*.c")
5050
```
5151

52-
#### 引入内置的辅助配置
52+
#### 引入内置的辅助配置 {#add-helper-configurations}
5353

5454
2.8.5 版本可以 includes 包含内置的一些辅助配置脚本,例如:
5555

@@ -81,7 +81,7 @@ includes("@builtin/check/check_cfuncs.lua")
8181

8282
而通过 `@builtin` 我们就能很好的区分是引入当前用户工程目录下的文件,还是 xmake 安装目录下的内置文件。
8383

84-
#### 作用域说明
84+
#### 作用域说明 {#scope-description}
8585

8686
includes 引入的配置是按树状层级结构来继承生效的,也就是当前 xmake.lua 中的全局配置,会对所有 includes 的子 xmake.lua 配置生效,例如:
8787

@@ -108,7 +108,7 @@ target("test")
108108
这种作用域隔离,能规避很多隐藏的配置冲突和作用域污染,在嵌套层级过多的工程配置中,隐式的全局引入,会导致很多的问题。
109109
:::
110110

111-
#### 模块化复用配置
111+
#### 模块化复用配置 {#modular-reusable}
112112

113113
那如果我想模块化复用配置,应该怎么做呢?只需要通过 function 去封装下需要复用的配置就行了,例如:
114114

0 commit comments

Comments
 (0)