update docs

docs/api/description/package-dependencies.md

@@ -229,6 +229,8 @@ add_urls(urls: <string|array>, ..., {
 | version | Version transformation function |
 | http_headers | HTTP headers for download |
 
+#### Usage
+
 Add the source package of the package or the git repository address. This interface is generally paired with add_version to set the version of each source package and the corresponding sha256 value.
 
 ::: tip NOTE
@@ -292,6 +294,8 @@ add_versions(version: <string>, hash: <string>)
 | version | Package version string |
 | hash | SHA256 hash value for verification |
 
+#### Usage
+
 Used to set the version of each source package and the corresponding sha256 value, as described in [add_urls](#add_urls)
 
 ## add_versionfiles
@@ -310,6 +314,8 @@ add_versionfiles(file: <string>)
 |-----------|-------------|
 | file | Version file path containing version and hash pairs |
 
+#### Usage
+
 Normally we can add package versions through the `add_versions` interface, but if there are more and more versions, the package configuration will be too bloated, at this time, we can use the `add_versionfiles` interface to store a list of all the versions in a separate file to maintain.
 
 For example:
@@ -346,6 +352,8 @@ add_patches(version: <string>, url: <string>, hash: <string>)
 | url | Patch file URL |
 | hash | SHA256 hash value for patch verification |
 
+#### Usage
+
 This interface is used for the source code package. Before compiling and installing, firstly set the corresponding patch package, compile it, and support multiple patches at the same time.
 
 ```lua
@@ -374,6 +382,8 @@ add_links(links: <string|array>, ...)
 | links | Library link name string or array |
 | ... | Variable parameters, can pass multiple link names |
 
+#### Usage
+
 By default, xmake will automatically detect the installed libraries and set the link relationship, but sometimes it is not very accurate. If you want to manually adjust the link order and the link name, you can set it through this interface.
 
 ```lua
@@ -397,6 +407,8 @@ add_syslinks(syslinks: <string|array>, ...)
 | syslinks | System library name string or array |
 | ... | Variable parameters, can pass multiple system library names |
 
+#### Usage
+
 Add some system library links. When some packages integrate links, you also need to rely on some system libraries to link them. This time you can attach them to the package description.
 
 ```lua
@@ -427,6 +439,8 @@ add_linkorders(orders: <string|array>, ...)
 | orders | Link order string or array |
 | ... | Variable parameters, can pass multiple order specifications |
 
+#### Usage
+
 For specific details, please see the target's internal documentation for `add_linkorders`, [target:add_linkorders](/api/description/project-target#add-linkorders).
 
 ```lua
@@ -457,6 +471,8 @@ add_linkgroups(groups: <string|array>, ..., {
 | name | Group name for linking |
 | group | Whether to treat as a group |
 
+#### Usage
+
 For specific details, please see the target's internal documentation for `add_linkgroups`, [target:add_linkgroups](/api/description/project-target#add-linkgroups).
 
 ```lua
@@ -482,6 +498,8 @@ add_frameworks(frameworks: <string|array>, ...)
 | frameworks | Framework name string or array |
 | ... | Variable parameters, can pass multiple framework names |
 
+#### Usage
+
 Add a dependent system frameworks link.
 
 See for example: [add_syslinks](#add_syslinks)
@@ -503,6 +521,8 @@ add_linkdirs(dirs: <string|array>, ...)
 | dirs | Link directory path string or array |
 | ... | Variable parameters, can pass multiple directory paths |
 
+#### Usage
+
 The package's link library search directory can also be adjusted, but it is usually not needed, unless some libraries are not installed under prefix/lib, but in the lib subdirectory, the default search is not available.
 
 ## add_includedirs
@@ -522,6 +542,8 @@ add_includedirs(dirs: <string|array>, ...)
 | dirs | Include directory path string or array |
 | ... | Variable parameters, can pass multiple directory paths |
 
+#### Usage
+
 Add another header file search directory.
 
 ## add_bindirs
@@ -541,6 +563,8 @@ add_bindirs(dirs: <string|array>, ...)
 | dirs | Executable directory path string or array |
 | ... | Variable parameters, can pass multiple directory paths |
 
+#### Usage
+
 By default, if `set_kind("binary")` or `set_kind("toolchain")` is configured as an executable package.
 
 Then, it will use the bin directory as an executable directory by default and automatically add it to the PATH environment variable.
@@ -566,6 +590,8 @@ add_defines(defines: <string|array>, ...)
 | defines | Macro definition string or array |
 | ... | Variable parameters, can pass multiple definitions |
 
+#### Usage
+
 Some specific definition options can be exported to the integrated package.
 
 ## add_configs
@@ -593,6 +619,8 @@ add_configs(name: <string>, {
 | values | Allowed values array |
 | type | Configuration type: "string", "boolean", "number" |
 
+#### Usage
+
 We can add the external output configuration parameters of each package through this interface:
 
 ```lua
@@ -649,6 +677,8 @@ add_extsources(sources: <string|array>, ...)
 | sources | External source string or array, format: "pkgconfig::name" or "brew::name" |
 | ... | Variable parameters, can pass multiple external sources |
 
+#### Usage
+
 Starting from version 2.5.2, we have also added two configuration interfaces `add_extsources` and `on_fetch`, which can better configure xmake to search for system libraries during the process of installing C/C++ packages.
 
 As for the specific background, we can give an example. For example, we added a package of `package("libusb")` to the [xmake-repo](https://github.com/xmake-io/xmake-repo) repository .
@@ -700,6 +730,8 @@ add_deps(deps: <string|array>, ...)
 | deps | Dependency package name string or array |
 | ... | Variable parameters, can pass multiple dependency names |
 
+#### Usage
+
 This interface allows us to automatically install all dependencies of a package when we install it by configuring the dependencies between packages.
 
 Also, by default, cmake/autoconf will automatically find the libraries and headers of all dependent packages as soon as we have configured the dependencies.
@@ -750,6 +782,8 @@ add_components(components: <string|array>, ..., {
 | ... | Variable parameters, can pass multiple component names |
 | deps | Component dependencies array |
 
+#### Usage
+
 This is a new interface added in 2.7.3 to support componentized configuration of packages, see: [#2636](https://github.com/xmake-io/xmake/issues/2636) for details.
 
 With this interface we can configure the list of components that are actually available for the current package.
@@ -792,6 +826,8 @@ set_base(package: <string>)
 |-----------|-------------|
 | package | Base package name to inherit from |
 
+#### Usage
+
 This is a newly added interface in 2.6.4, through which we can inherit all the configuration of an existing package, and then rewrite some of the configuration on this basis.
 
 This is usually in the user's own project, it is more useful to modify the built-in package of the xmake-repo official repository, such as: repairing and changing urls, modifying the version list, installation logic, etc.
@@ -837,6 +873,8 @@ on_load(script: <function (package)>)
 |-----------|-------------|
 | script | Package load script function with package parameter |
 
+#### Usage
+
 This is an optional interface. If you want to be more flexible and dynamically judge various platform architectures, you can do it in this way, for example:
 
 ```lua
@@ -871,6 +909,8 @@ on_fetch(platforms: <string|array>, ..., script: <function (package, opt)>)
 | ... | Variable parameters, can pass multiple platform filters |
 | script | Fetch script function with package and opt parameters |
 
+#### Usage
+
 This is an optional configuration. After 2.5.2, if the system libraries installed under different systems only have different package names, then using `add_extsources` to improve the system library search is sufficient, simple and convenient.
 
 However, if some packages are installed in the system, the location is more complicated. To find them, some additional scripts may be needed. For example: access to the registry under windows to find packages, etc. At this time, we can use `on_fetch `Fully customized search system library logic.
@@ -906,6 +946,8 @@ on_check(platforms: <string|array>, ..., script: <function (package)>)
 | ... | Variable parameters, can pass multiple platform filters |
 | script | Check script function with package parameter |
 
+#### Usage
+
 Sometimes, simply using `on_install("windows", "android", function () end)` cannot properly limit the package's support for the current platform.
 
 For example, it is also compiled using msvc on windows, but it only supports using the vs2022 tool chain. Then we cannot simply restrict the installation of packages by disabling the windows platform.
@@ -969,6 +1011,8 @@ on_install(platforms: <string|array>, ..., script: <function (package)>)
 | ... | Variable parameters, can pass multiple platform filters |
 | script | Install script function with package parameter |
 
+#### Usage
+
 This interface is mainly used to add installation scripts. The previous string parameters are used to set supported platforms. Other script fields such as `on_load`, `on_test` are also supported.
 
 ### Platform filtering
@@ -1155,6 +1199,8 @@ on_download(script: <function (package, opt)>)
 |-----------|-------------|
 | script | Download script function with package and opt parameters |
 
+#### Usage
+
 The download logic of the custom package, which is a new interface added in 2.6.4, is usually not used, and it is enough to use the built-in download of Xmake.
 
 If the user builds a private repository and has a more complex authentication mechanism and special processing logic for the download of the package, the internal download logic can be rewritten to achieve this.
@@ -1434,6 +1480,8 @@ on_test(script: <function (package)>)
 |-----------|-------------|
 | script | Test script function with package parameter |
 
+#### Usage
+
 After installation, you need to set the corresponding test script, perform some tests to ensure the reliability of the installation package, if the test does not pass, the entire installation package will be revoked.
 
 ```lua
@@ -1506,6 +1554,8 @@ on_component(component: <string>, script: <function (package, component)>)
 | component | Component name string, optional (if not provided, applies to all components) |
 | script | Component configuration script function with package and component parameters |
 
+#### Usage
+
 This is a new interface added in 2.7.3 to support component-based configuration of packages, see: [#2636](https://github.com/xmake-io/xmake/issues/2636) for details.
 
 Through this interface we can configure the current package, specifying component details such as links to components, dependencies etc.

docs/api/description/xpack-component-interfaces.md

@@ -16,6 +16,8 @@ set_title(title: <string>)
 |-----------|-------------|
 | title | Component title string |
 
+#### Usage
+
 ```lua
 xpack_component("LongPath")
      set_title("Enable Long Path")
@@ -37,6 +39,8 @@ set_description(description: <string>)
 |-----------|-------------|
 | description | Component description string |
 
+#### Usage
+
 ```lua
 xpack_component("LongPath")
      set_description("Increases the maximum path length limit, up to 32,767 characters (before 256).")
@@ -58,6 +62,8 @@ set_default(default: <boolean>)
 |-----------|-------------|
 | default | Whether component is enabled by default (boolean) |
 
+#### Usage
+
 Usually the package component is enabled by default, but we can also use this interface to disable this component by default. Only when the user chooses to check this component when installing the package will it be enabled for installation.
 
 ```lua
@@ -82,6 +88,8 @@ on_load(script: <function (component)>)
 |-----------|-------------|
 | script | Load script function with component parameter |
 
+#### Usage
+
 We can further flexibly configure package components in the on_load custom script field.
 
 ```lua
@@ -108,6 +116,8 @@ before_installcmd(script: <function (component, batchcmds)>)
 |-----------|-------------|
 | script | Before install script function with component and batchcmds parameters |
 
+#### Usage
+
 It will not rewrite the entire installation script, but will add some custom installation scripts before the existing installation scripts are executed:
 
 ```lua
@@ -139,6 +149,10 @@ on_installcmd(script: <function (component, batchcmds)>)
 |-----------|-------------|
 | script | Install script function with component and batchcmds parameters |
 
+#### Usage
+
+Custom installation script for implementing specific component installation logic.
+
 This will rewrite the entire component's installation script, similar to xpack's on_installcmd.
 
 ```lua
@@ -164,6 +178,10 @@ after_installcmd(script: <function (component, batchcmds)>)
 |-----------|-------------|
 | script | After install script function with component and batchcmds parameters |
 
+#### Usage
+
+Custom script executed after component installation, used for post-processing operations.
+
 After the component is installed, the script here will be executed, similar to xpack's after_installcmd.
 
 ```lua
@@ -214,6 +232,10 @@ on_uninstallcmd(script: <function (component, batchcmds)>)
 |-----------|-------------|
 | script | Uninstall script function with component and batchcmds parameters |
 
+#### Usage
+
+Custom uninstall script for implementing specific component uninstall logic.
+
 This will rewrite the entire component's uninstall script, similar to xpack's on_uninstallcmd.
 
 ```lua
@@ -239,6 +261,10 @@ after_uninstallcmd(script: <function (component, batchcmds)>)
 |-----------|-------------|
 | script | After uninstall script function with component and batchcmds parameters |
 
+#### Usage
+
+Custom script executed after component uninstallation, used for post-processing operations.
+
 After the component is uninstalled, the script here will be executed, similar to xpack's before_uninstallcmd.
 
 ```lua
@@ -298,4 +324,6 @@ add_installfiles(files: <string|array>, ..., {
 | rootdir | Source root directory |
 | filename | Target filename |
 
+#### Usage
+
 This is similar to xpack's add_installfiles, but here only the binaries are added to the installation package when the component is enabled.

docs/api/description/xpack-interfaces.md

@@ -125,6 +125,8 @@ set_description(description: <string>)
 |-----------|-------------|
 | description | Package description string |
 
+#### Usage
+
 This interface can set more detailed description information of the installation package. You can use one or two sentences to describe the package in detail.
 
 ```lua
@@ -148,6 +150,8 @@ set_author(author: <string>)
 |-----------|-------------|
 | author | Author information string |
 
+#### Usage
+
 We can set the email address, name, etc. to describe the author of this package.
 
 ```lua
@@ -171,6 +175,8 @@ set_maintainer(maintainer: <string>)
 |-----------|-------------|
 | maintainer | Maintainer information string |
 
+#### Usage
+
 We can set the email address, name, etc. to describe the maintainer of this package.
 
 The maintainer and author may or may not be the same person.

docs/zh/api/description/package-dependencies.md

@@ -223,6 +223,8 @@ add_urls(urls: <string|array>, ..., {
 | version | 版本转换函数 |
 | http_headers | 下载时的HTTP头 |
 
+#### 用法说明
+
 添加包的源码包或者git仓库地址，此接口一般跟add_version配对使用，用于设置每个源码包的版本和对应的sha256值或者git的commit或者tag或者branch。
 
 ::: tip 注意
@@ -286,6 +288,8 @@ add_versions(version: <string>, hash: <string>)
 | version | 包版本字符串 |
 | hash | 用于验证的SHA256哈希值 |
 
+#### 用法说明
+
 它也会设置对应的sha256值，具体描述见：[add_urls](#add_urls)
 
 ## add_versionfiles
@@ -304,6 +308,8 @@ add_versionfiles(file: <string>)
 |------|------|
 | file | 包含版本和哈希值对的文件路径 |
 
+#### 用法说明
+
 通常我们可以通过 `add_versions` 接口添加包版本，但是如果版本越来越多，就会导致包配置太过臃肿，这个时候，我们可以使用 `add_versionfiles` 接口将所有的版本列表，存储到单独的文件中去维护。
 
 例如：
@@ -340,6 +346,8 @@ add_patches(version: <string>, url: <string>, hash: <string>)
 | url | 补丁文件URL |
 | hash | 补丁验证的SHA256哈希值 |
 
+#### 用法说明
+
 此接口用于针对源码包，在编译安装前，先打对应设置的补丁包，再对其进行编译，并且可支持同时打多个补丁。
 
 ```lua
@@ -368,6 +376,8 @@ add_links(links: <string|array>, ...)
 | links | 库链接名称字符串或数组 |
 | ... | 可变参数，可传入多个链接名称 |
 
+#### 用法说明
+
 默认情况下，xmake会去自动检测安装后的库，设置链接关系，但是有时候并不是很准，如果要自己手动调整链接顺序，以及链接名，则可以通过这个接口来设置。
 
 ```lua
@@ -391,6 +401,8 @@ add_syslinks(syslinks: <string|array>, ...)
 | syslinks | 系统库名称字符串或数组 |
 | ... | 可变参数，可传入多个系统库名称 |
 
+#### 用法说明
+
 添加一些系统库链接，有些包集成链接的时候，还需要依赖一些系统库，才能链接通过，这个时候可以在包描述里面都附加上去。
 
 ```lua
@@ -421,6 +433,8 @@ add_linkorders(orders: <string|array>, ...)
 | orders | 链接顺序字符串或数组 |
 | ... | 可变参数，可传入多个顺序规格 |
 
+#### 用法说明
+
 具体详情可以看下 target 内部对 `add_linkorders` 的文档说明，[target:add_linkorders](/zh/api/description/project-target#add_linkorders)。
 
 ```lua
@@ -451,6 +465,8 @@ add_linkgroups(groups: <string|array>, ..., {
 | name | 用于链接的组名称 |
 | group | 是否作为组处理 |
 
+#### 用法说明
+
 具体详情可以看下 target 内部对 `add_linkgroups` 的文档说明，[target:add_linkgroups](/zh/api/description/project-target#add-linkgroups)。
 
 ```lua
@@ -476,6 +492,8 @@ add_frameworks(frameworks: <string|array>, ...)
 | frameworks | 框架名称字符串或数组 |
 | ... | 可变参数，可传入多个框架名称 |
 
+#### 用法说明
+
 示例见：[add_syslinks](#add_syslinks)
 
 ## add_linkdirs
@@ -495,6 +513,8 @@ add_linkdirs(dirs: <string|array>, ...)
 | dirs | 链接目录路径字符串或数组 |
 | ... | 可变参数，可传入多个目录路径 |
 
+#### 用法说明
+
 包的链接库搜索目录也是可以调整的，不过通常都不需要，除非一些库安装完不在prefix/lib下面，而在lib的子目录下，默认搜索不到的话。
 
 ## add_includedirs
@@ -514,6 +534,10 @@ add_includedirs(dirs: <string|array>, ...)
 | dirs | 头文件目录路径字符串或数组 |
 | ... | 可变参数，可传入多个目录路径 |
 
+#### 用法说明
+
+添加其他头文件搜索目录，用于指定包的头文件位置。
+
 ## add_bindirs
 
 - 添加可执行文件目录
@@ -531,6 +555,8 @@ add_bindirs(dirs: <string|array>, ...)
 | dirs | 可执行文件目录路径字符串或数组 |
 | ... | 可变参数，可传入多个目录路径 |
 
+#### 用法说明
+
 默认情况下，如果配置了 `set_kind("binary")` 或者 `set_kind("toolchain")` 作为可执行的包。
 
 那么，它默认会将 bin 目录作为可执行目录，并且自动将它加入到 PATH 环境变量中去。
@@ -556,6 +582,8 @@ add_defines(defines: <string|array>, ...)
 | defines | 宏定义字符串或数组 |
 | ... | 可变参数，可传入多个定义 |
 
+#### 用法说明
+
 可以对集成的包对外输出一些特定的定义选项。
 
 ## add_configs
@@ -583,6 +611,8 @@ add_configs(name: <string>, {
 | values | 允许的值数组 |
 | type | 配置类型："string", "boolean", "number" |
 
+#### 用法说明
+
 我们可以通过此接口添加每个包的对外输出配置参数：
 
 ```lua
@@ -637,7 +667,10 @@ add_extsources(sources: <string|array>, ...)
 | 参数 | 描述 |
 |------|------|
 | sources | 外部源字符串或数组，格式："pkgconfig::name" 或 "brew::name" |
-| ... | 可变参数，可传入多个外部源 |
+
+#### 用法说明
+
+添加扩展的包源，用于指定包的外部源。
 
 2.5.2 版本开始，我们也新增了 `add_extsources` 和 `on_fetch` 两个配置接口，可以更好的配置 xmake 在安装 C/C++ 包的过程中，对系统库的查找过程。
 
@@ -690,6 +723,10 @@ add_deps(deps: <string|array>, ...)
 | deps | 依赖包名称字符串或数组 |
 | ... | 可变参数，可传入多个依赖名称 |
 
+#### 用法说明
+
+添加包依赖，用于指定包之间的依赖关系。
+
 添加包依赖接口，通过配置包之间的依赖关系，我们能够在安装包的同时，自动安装它的所有依赖包。
 
 另外，默认情况下，我们只要配置了依赖关系，cmake/autoconf 就能够自动找到所有依赖包的库和头文件。
@@ -740,6 +777,10 @@ add_components(components: <string|array>, ..., {
 | ... | 可变参数，可传入多个组件名称 |
 | deps | 组件依赖数组 |
 
+#### 用法说明
+
+添加包组件，用于指定包的组件结构。
+
 这是 2.7.3 新加的接口，用于支持包的组件化配置，详情见：[#2636](https://github.com/xmake-io/xmake/issues/2636)。
 
 通过这个接口，我们可以配置当前包实际可以提供的组件列表。
@@ -782,6 +823,8 @@ set_base(package: <string>)
 |------|------|
 | package | 要继承的基础包名称 |
 
+#### 用法说明
+
 这是 2.6.4 新加的接口，我们可以通过它去继承一个已有的包的全部配置，然后在此基础上重写部分配置。
 
 这通常在用户自己的项目中，修改 xmake-repo 官方仓库的内置包比较有用，比如：修复改 urls，修改版本列表，安装逻辑等等。
@@ -827,6 +870,8 @@ on_load(script: <function (package)>)
 |------|------|
 | script | 包加载脚本函数，参数为package |
 
+#### 用法说明
+
 这是个可选的接口，如果要更加灵活的动态判断各种平台架构，针对性做设置，可以在这个里面完成，例如：
 
 ```lua
@@ -859,6 +904,8 @@ on_fetch(platforms: <string|array>, ..., script: <function (package, opt)>)
 | ... | 可变参数，可传入多个平台过滤器 |
 | script | 查找脚本函数，参数为package和opt |
 
+#### 用法说明
+
 这是个可选配置，2.5.2 之后，如果不同系统下安装的系统库，仅仅只是包名不同，那么使用 `add_extsources` 改进系统库查找已经足够，简单方便。
 
 但是如果有些安装到系统的包，位置更加复杂，想要找到它们，也许需要一些额外的脚本才能实现，例如：windows 下注册表的访问去查找包等等，这个时候，我们就可以通过 `on_fetch` 完全定制化查找系统库逻辑。
@@ -892,6 +939,8 @@ on_check(platforms: <string|array>, ..., script: <function (package)>)
 | ... | 可变参数，可传入多个平台过滤器 |
 | script | 检测脚本函数，参数为package |
 
+#### 用法说明
+
 有时候，单纯用 `on_install("windows", "android", function () end)` 无法很好的限制包对当前平台的支持力度。
 
 例如，同样都是在 windows 上使用 msvc 编译，但是它仅仅只支持使用 vs2022 工具链。那么我们无法简单的去通过禁用 windows 平台，来限制包的安装。
@@ -955,6 +1004,8 @@ on_install(platforms: <string|array>, ..., script: <function (package)>)
 | ... | 可变参数，可传入多个平台过滤器 |
 | script | 安装脚本函数，参数为package |
 
+#### 用法说明
+
 这个接口主要用于添加安装脚本，前面的字符串参数用于设置支持的平台，像`on_load`, `on_test`等其他脚本域也是同样支持的。
 
 ### 平台过滤
@@ -1141,6 +1192,8 @@ on_test(script: <function (package)>)
 |------|------|
 | script | 测试脚本函数，参数为package |
 
+#### 用法说明
+
 安装后，需要设置对应的测试脚本，执行一些测试，确保安装包的可靠性，如果测试不通过，则会撤销整个安装包。
 
 ```lua
@@ -1212,6 +1265,10 @@ on_download(script: <function (package, opt)>)
 |------|------|
 | script | 下载脚本函数，参数为package和opt |
 
+#### 用法说明
+
+自定义下载包，用于指定包的下载方式。
+
 自定义包的下载逻辑，这是 2.6.4 新加的接口，通常用不到，使用 Xmake 的内置下载就足够了。
 
 如果用户自建私有仓库，对包的下载有更复杂的鉴权机制，特殊处理逻辑，那么可以重写内部的下载逻辑来实现。
@@ -1299,6 +1356,8 @@ on_component(component: <string>, script: <function (package, component)>)
 | component | 组件名称字符串，可选（如果不提供，则应用于所有组件） |
 | script | 组件配置脚本函数，参数为package和component |
 
+#### 用法说明
+
 这是 2.7.3 新加的接口，用于支持包的组件化配置，详情见：[#2636](https://github.com/xmake-io/xmake/issues/2636)。
 
 通过这个接口，我们可以配置当前包，指定组件的详细信息，比如组件的链接，依赖等等。

docs/zh/api/description/xpack-component-interfaces.md

@@ -16,6 +16,8 @@ set_title(title: <string>)
 |------|------|
 | title | 组件标题字符串 |
 
+#### 用法说明
+
 ```lua
 xpack_component("LongPath")
     set_title("Enable Long Path")
@@ -37,6 +39,8 @@ set_description(description: <string>)
 |------|------|
 | description | 组件详细描述字符串 |
 
+#### 用法说明
+
 ```lua
 xpack_component("LongPath")
     set_description("Increases the maximum path length limit, up to 32,767 characters (before 256).")
@@ -58,6 +62,8 @@ set_default(default: <boolean>)
 |------|------|
 | default | 是否默认启用（布尔值） |
 
+#### 用法说明
+
 通常包组件都会被默认启用，但是我们也可以使用这个接口，默认禁用这个组件，仅仅当用户安装包时候，选择勾选此组件，才会被启用安装。
 
 ```lua
@@ -82,6 +88,10 @@ on_load(script: <function (component)>)
 |------|------|
 | script | 加载脚本函数，参数为component |
 
+#### 用法说明
+
+自定义加载脚本，用于实现特定的组件配置逻辑。
+
 我们可以在 on_load 自定义脚本域中，进一步灵活的配置包组件。
 
 ```lua
@@ -139,6 +149,10 @@ on_installcmd(script: <function (component, batchcmds)>)
 |------|------|
 | script | 安装脚本函数，参数为component和batchcmds |
 
+#### 用法说明
+
+自定义安装脚本，用于实现特定的组件安装逻辑。
+
 这会重写整个组件的安装脚本，类似 xpack 的 on_installcmd。
 
 ```lua
@@ -164,6 +178,10 @@ after_installcmd(script: <function (component, batchcmds)>)
 |------|------|
 | script | 安装后脚本函数，参数为component和batchcmds |
 
+#### 用法说明
+
+在组件安装完成后执行的自定义脚本，用于后处理操作。
+
 在组件安装之后，会执行这里的脚本，类似 xpack 的 after_installcmd。
 
 ```lua
@@ -214,6 +232,10 @@ on_uninstallcmd(script: <function (component, batchcmds)>)
 |------|------|
 | script | 卸载脚本函数，参数为component和batchcmds |
 
+#### 用法说明
+
+自定义卸载脚本，用于实现特定的组件卸载逻辑。
+
 这会重写整个组件的卸载脚本，类似 xpack 的 on_uninstallcmd。
 
 ```lua
@@ -239,6 +261,10 @@ after_uninstallcmd(script: <function (component, batchcmds)>)
 |------|------|
 | script | 卸载后脚本函数，参数为component和batchcmds |
 
+#### 用法说明
+
+在组件卸载完成后执行的自定义脚本，用于后处理操作。
+
 在组件卸载之后，会执行这里的脚本，类似 xpack 的 before_uninstallcmd。
 
 ```lua
@@ -298,4 +324,6 @@ add_installfiles(files: <string|array>, ..., {
 | rootdir | 源文件根目录 |
 | filename | 目标文件名 |
 
+#### 用法说明
+
 这类似于 xpack 的 add_installfiles，但这里仅仅当组件被启用后，才会将这些二进制文件打入安装包。

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

@@ -125,6 +125,8 @@ set_description(description: <string>)
 |------|------|
 | description | 包详细描述字符串 |
 
+#### 用法说明
+
 这个接口可以设置安装包更加详细的描述信息，可以用一到两句话详细描述下包。
 
 ```lua
@@ -148,6 +150,8 @@ set_author(author: <string>)
 |------|------|
 | author | 作者信息字符串 |
 
+#### 用法说明
+
 我们可以设置邮箱，姓名等来描述这个包的作者。
 
 ```lua
@@ -171,6 +175,8 @@ set_maintainer(maintainer: <string>)
 |------|------|
 | maintainer | 维护者信息字符串 |
 
+#### 用法说明
+
 我们可以设置邮箱，姓名等来描述这个包的维护者。
 
 维护者跟作者有可能是同一个人，也可能不是一个人。
@@ -196,6 +202,8 @@ set_copyright(copyright: <string>)
 |------|------|
 | copyright | 版权信息字符串 |
 
+#### 用法说明
+
 ```lua
 xpack("xmake")
     set_copyright("Copyright (C) 2015-present, TBOOX Open Source Group")
@@ -217,6 +225,8 @@ set_license(license: <string>)
 |------|------|
 | license | License名称字符串 |
 
+#### 用法说明
+
 目前像 srpm/rpm/deb 等包会用到，用于设置 License 名。
 
 ```lua
@@ -239,6 +249,8 @@ set_licensefile(licensefile: <string>)
 |------|------|
 | licensefile | License文件路径字符串 |
 
+#### 用法说明
+
 我们可以设置 LICENSE 所在的文件路径，像 NSIS 的安装包，它还会额外将 LICENSE 页面展示给安装用户。
 
 ```lua
@@ -262,6 +274,8 @@ set_company(company: <string>)
 |------|------|
 | company | 公司名称字符串 |
 
+#### 用法说明
+
 我们可以用这个接口设置包所属的公司和组织名。
 
 ```lua
@@ -285,6 +299,8 @@ set_inputkind(inputkind: <string>)
 |------|------|
 | inputkind | 输入源类型: "binary" 或 "source" |
 
+#### 用法说明
+
 这是个可选接口，可用于标识当前打包的输入源类型
 
 - binary: 从二进制文件作为输入源打包，通常使用 `add_installfiles`
@@ -332,6 +348,8 @@ set_formats(formats: <string|array>, ...)
 | formats | 打包格式名称字符串或数组 |
 | ... | 可变参数，可传递多个格式名称 |
 
+#### 用法说明
+
 配置当前 XPack 包需要生成的打包格式，可以同时配置多个，`xmake pack` 命令会一次性全部生成。
 
 ::: tip 注意
@@ -382,6 +400,8 @@ set_basename(basename: <string>)
 |------|------|
 | basename | 包文件名字符串（不含扩展名） |
 
+#### 用法说明
+
 设置生成包的文件名，但不包含后缀名。
 
 ```lua
@@ -416,6 +436,8 @@ set_extension(extension: <string>)
 |------|------|
 | extension | 包扩展名字符串 |
 
+#### 用法说明
+
 通常我们并不需要修改生成包的扩展名，因为指定了 `nsis`, `zip` 等格式后，都会有一个默认的后缀名，例如：`.exe`, `.zip`。
 
 但是，如果我们正在自定义包格式，需要生成一个自定义的包，那么我们可能需要配置它。
@@ -451,6 +473,8 @@ add_targets(targets: <string|array>, ...)
 | targets | 目标名称字符串或数组 |
 | ... | 可变参数，可传递多个目标名称 |
 
+#### 用法说明
+
 我们可以通过这个接口，配置关联需要被安装的目标 target。
 
 ```lua
@@ -486,6 +510,8 @@ add_components(components: <string|array>, ...)
 | components | 组件名称字符串或数组 |
 | ... | 可变参数，可传递多个组件名称 |
 
+#### 用法说明
+
 我们也支持为安装包添加自定义组件，按组件模式进行选择安装。目前仅仅对 NSIS 包会有比较的支持效果。
 
 我们可以通过 `xpack_component()` 定义一个组件域，然后使用 `add_components()` 加指定的组件跟包进行关联绑定。
@@ -534,6 +560,8 @@ set_bindir(bindir: <string>)
 |------|------|
 | bindir | 二进制安装目录字符串 |
 
+#### 用法说明
+
 通常生成的安装包都会有一个安装根目录，而我们可以通过这个配置指定安装目录下的 bin 目录位置。
 
 如果没有指定，默认在 `installdir/bin`。
@@ -563,6 +591,8 @@ set_libdir(libdir: <string>)
 |------|------|
 | libdir | 库安装目录字符串 |
 
+#### 用法说明
+
 通常生成的安装包都会有一个安装根目录，而我们可以通过这个配置指定安装目录下的 lib 目录位置。
 
 如果没有指定，默认在 `installdir/lib`。
@@ -593,6 +623,8 @@ set_includedir(includedir: <string>)
 |------|------|
 | includedir | 头文件安装目录字符串 |
 
+#### 用法说明
+
 通常生成的安装包都会有一个安装根目录，而我们可以通过这个配置指定安装目录下的 include 目录位置。
 
 如果没有指定，默认在 `installdir/include`。
@@ -622,6 +654,8 @@ set_prefixdir(prefixdir: <string>)
 |------|------|
 | prefixdir | 安装前缀目录字符串 |
 
+#### 用法说明
+
 如果配置了
 
 ```lua
@@ -655,6 +689,8 @@ set_specfile(specfile: <string>)
 |------|------|
 | specfile | spec文件路径字符串 |
 
+#### 用法说明
+
 有些包格式的生成，需要先生成特定的 spec 文件，然后才能调用第三方打包工具去生成包。
 
 比如 NSIS 包，需要先通过 xmake 根据 xpack 配置，生成 NSIS 特有的 `.nsi` 配置文件，然后 xmake 会再调用 `makensis.exe` 去根据这个 `.nsi` 文件生成 NSIS 包。
@@ -725,6 +761,8 @@ set_specvar(name: <string>, value: <string>)
 | name | 变量名称字符串 |
 | value | 变量值字符串 |
 
+#### 用法说明
+
 通常配合 `set_specfile` 接口一起使用，用于在自定义的 spec 模版文件里面，设置一些自定义的包变量。
 
 ```lua
@@ -759,6 +797,8 @@ set_iconfile(iconfile: <string>)
 |------|------|
 | iconfile | 图标文件路径字符串 |
 
+#### 用法说明
+
 我们可以额外配置一个 ico 的图标文件，可以用于设置 NSIS 等一些支持图标自定义的安装包的图标。
 
 ```lua
@@ -790,6 +830,8 @@ add_sourcefiles(files: <string|array>, ..., {
 | rootdir | 源文件根目录 |
 | filename | 目标文件名 |
 
+#### 用法说明
+
 这通常用于源码包，也就是 `srczip`, `srctargz` 这种纯源码包，以及 `runself` 格式的源码安装包。
 
 如果是自定义的包格式，我们需要配置 `set_inputkind("source")` 开启源码包。
@@ -822,6 +864,8 @@ add_installfiles(files: <string|array>, ..., {
 | rootdir | 源文件根目录 |
 | filename | 目标文件名 |
 
+#### 用法说明
+
 这通常用于二进制包，也就是 `nsis`, `deb` 等格式的包，这些包会直接安装二进制文件。
 
 因此，我们可以通过这个接口额外配置一些需要被安装的二进制文件，比如：可执行文件，资源文件等等。
@@ -869,6 +913,10 @@ add_buildrequires(requires: <string|array>, ...)
 | requires | 构建依赖名称字符串或数组 |
 | ... | 可变参数，可传递多个依赖名称 |
 
+#### 用法说明
+
+添加包的构建依赖，用于指定包构建时需要的依赖项。
+
 这通常用于一些源码包，例如 srpm。这些源码包在安装之前，需要先构建源码，而构建源码可能会需要用到一些其他的依赖包。
 
 我们可以通过这个接口去配置它们。
@@ -907,6 +955,8 @@ on_load(script: <function (package)>)
 |------|------|
 | script | 加载脚本函数，参数为package |
 
+#### 用法说明
+
 如果在描述域中配置无法满足我们的需求，还可以在 on_load 自定义脚本域中，进一步灵活的配置包。
 
 这个接口会在每个 XPack 包初始化加载期间就被调用，可以在里面做一些基础配置。
@@ -936,6 +986,8 @@ before_package(script: <function (package)>)
 |------|------|
 | script | 打包前脚本函数，参数为package |
 
+#### 用法说明
+
 我们可以通过这个接口配置打包之前的自定义脚本。
 
 ```lua
@@ -961,6 +1013,10 @@ on_package(script: <function (package)>)
 |------|------|
 | script | 打包脚本函数，参数为package |
 
+#### 用法说明
+
+自定义打包脚本，用于实现特定的打包逻辑。
+
 我们可以通过这个接口配置打包自定义脚本，这将会重写整个内置的打包逻辑。通常用于自定义包格式。
 
 ```lua
@@ -987,6 +1043,10 @@ after_package(script: <function (package)>)
 |------|------|
 | script | 打包后脚本函数，参数为package |
 
+#### 用法说明
+
+在打包完成后执行的自定义脚本，用于后处理操作。
+
 我们可以通过这个接口配置打包之后的自定义脚本。
 
 ```lua
@@ -1012,6 +1072,10 @@ before_installcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 安装前脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+在安装之前执行的自定义脚本，用于准备安装环境。
+
 它不会重写整个安装脚本，但是会在现有的安装脚本执行之前，新增一些自定义的安装脚本：
 
 ```lua
@@ -1041,6 +1105,10 @@ on_buildcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 构建脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+自定义构建脚本，用于实现特定的构建逻辑。
+
 对于一些源码构建包，在安装之前，我们需要先构建源码，例如 srpm 包。
 
 因此，我们可以通过这个接口，自定义构建脚本，例如：
@@ -1083,6 +1151,10 @@ before_buildcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 构建前脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+在构建之前执行的自定义脚本，用于准备构建环境。
+
 通过这个接口，我们可以配置构建之前的脚本。
 
 ```lua
@@ -1109,6 +1181,10 @@ after_buildcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 构建后脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+在构建完成后执行的自定义脚本，用于后处理操作。
+
 通过这个接口，我们可以配置构建之后的脚本。
 
 ```lua
@@ -1135,6 +1211,10 @@ on_installcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 安装脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+自定义安装脚本，用于实现特定的安装逻辑。
+
 这回完全重写内置默认的安装脚本，包括内部对 `add_installfiles` 配置的文件的自动安装，用户需要完全自己处理所有的安装逻辑。
 
 ## after_installcmd
@@ -1153,6 +1233,10 @@ after_installcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 安装后脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+在安装完成后执行的自定义脚本，用于后处理操作。
+
 它不会重写整个安装脚本，但是会在现有的安装脚本执行之后，新增一些自定义的安装脚本：
 
 ```lua
@@ -1182,6 +1266,10 @@ before_uninstallcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 卸载前脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+在卸载之前执行的自定义脚本，用于准备卸载环境。
+
 跟 before_installcmd 类似，请参考 before_installcmd 说明。
 
 ## on_uninstallcmd
@@ -1200,6 +1288,10 @@ on_uninstallcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 卸载脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+自定义卸载脚本，用于实现特定的卸载逻辑。
+
 跟 on_installcmd 类似，请参考 on_installcmd 说明。
 
 ## after_uninstallcmd
@@ -1218,6 +1310,10 @@ after_uninstallcmd(script: <function (package, batchcmds)>)
 |------|------|
 | script | 卸载后脚本函数，参数为package和batchcmds |
 
+#### 用法说明
+
+在卸载完成后执行的自定义脚本，用于后处理操作。
+
 跟 after_installcmd 类似，请参考 after_installcmd 说明。
 
 ## set_nsis_displayicon
@@ -1236,6 +1332,8 @@ set_nsis_displayicon(iconfile: <string>)
 |------|------|
 | iconfile | 图标文件路径字符串 |
 
+#### 用法说明
+
 这是一个 NSIS 专有 API，可以用于配置 NSIS 的显示图标：
 
 ```lua