制品包使用

正确配置中心仓仓库地址后，即可从中心仓获取并使用制品包。

中心仓依赖项

中心仓内的制品包对应一个 cjpm 模块，因此可以被本地开发的 cjpm 模块以依赖项的形式导入。

cjpm 中心仓依赖项格式如下：

[dependencies]
  dep1 = "1.0.0"                # 依赖版本号为 1.0.0 的制品 dep1
  dep2 = { version = "2.0.0" }  # 依赖版本号为 2.0.0 的制品 dep2，该写法等价于 dep2 = "2.0.0"
  dep3 = "[1.0.0, 3.0.0)"       # 依赖版本号大于等于 1.0.0，小于 3.0.0 的任意版本的制品 dep3
  "org::dep4" = "4.0.0"         # 依赖版本号为 4.0.0，并且隶属于 org 组织的制品 dep4

配置方式具体说明如下：

• 中心仓依赖项配置格式为 ${制品名} = "${版本需求}" 或 ${制品名} = { version = "${版本需求}" }，两种写法等价；
• 依赖组织内制品时，需要将组织名添加在制品名中，以 :: 分隔，并且由于 toml 格式的要求，需要使用 "" 包含，例如上例的 "org::dep4" = "4.0.0"；
• 版本需求支持如下格式：
  • 单一版本号：表示依赖特定版本的制品包，例如上例中 dep1 = "1.0.0"；
  • 版本范围：以数学区间表示的版本范围，可自定义开闭区间，表示依赖范围内任意版本的制品包，例如上例中 dep3 = "[1.0.0, 3.0.0)" 表示依赖任意一个版本号大于等于 1.0.0，小于 3.0.0 的 dep3 制品包；
    • 无限版本范围：版本范围上下界可缺省，表示无上界/下界，缺省处必须为开区间，例如 (, 2.0.0] 表示任意小于等于 2.0.0 的版本，(1.0.0, ) 表示任意大于 1.0.0 的版本，(, ) 表示任意版本；
  • 多区间组合：任意个数的单一版本号或版本范围的组合，用逗号分隔，表示制品包版本满足其中任意单一版本号或版本范围即可，例如 (, 1.0.0), [2.0.0, 3.0.0), 4.0.0 表示依赖的制品包的版本小于 1.0.0，或是大于等于 2.0.0 并小于 3.0.0，或是 4.0.0 版本。

注意：

制品版本号之间按主版本号、次版本号、修订版本号的优先级顺序依次比较以确定大小关系，高优先级的版本大小关系确定后，即忽略低优先级的版本大小关系。例如：1.2.3 < 1.4.5, 3.4.5 > 2.40.50。

不同场景的依赖项

cjpm 在项目配置文件 cjpm.toml 中提供了三种源码依赖模块配置方式，均遵守上述格式，分别对应不同的应用场景：

• 项目依赖 dependencies: 用于为项目文件（除了构建脚本 build.cj）提供源码依赖模块；
• 测试依赖 test-dependencies: 用于为项目的测试代码提供源码依赖模块，测试代码文件名须以 _test.cj 结尾；测试依赖仅在测试环节生效；
• 脚本依赖 script-dependencies: 用于为项目的构建脚本提供源码依赖模块，构建脚本是与 cjpm.toml 同级的名为 build.cj 的文件；脚本依赖仅对构建脚本生效。

注意：

• 项目源码依赖 dependencies 也可用于项目的测试代码；
• 构建脚本与项目源码相互独立，因此构建脚本只能使用 script-dependencies 中的依赖项，不能使用另外两类依赖项，同时项目的源码和测试代码也不能使用 script-dependencies 中的依赖项。

例如，有如下结构的本地模块 demo：

demo
├── src
│    ├── demo.cj
│    └── demo_test.cj
├── build.cj
└── cjpm.toml

模块 demo 配置了如下依赖：

# demo/cjpm.toml
[package]
  name = "demo"

[dependencies]
  dep1 = "1.0.0"

[test-dependencies]
  "org::dep2" = "2.0.0"

[script-dependencies]
  dep3 = "3.0.0"

则在 demo 的不同源码文件中可以依赖对应中心仓模块内的任意包：

// src/demo.cj
package demo
import dep1.aoo.*         // 源码文件可以依赖模块 dep1 中的包

// src/demo_test.cj
package demo
import dep1.aoo.*         // 测试文件可以依赖模块 dep1 中的包
import org::dep2.boo.*    // 测试文件可以依赖模块 org::dep2 中的包

// build.cj
import dep3.coo.*         // 构建脚本可以依赖模块 dep3 中的包

平台隔离依赖项

cjpm 支持使用 target 字段隔离不同平台和不同编译模式的依赖项配置，例如：

# demo/cjpm.toml
[target.x86_64-unknown-linux-gnu.debug.dependencies]
  dep1 = "1.0.0"  # linux-x64 平台以 debug(-g) 模式进行编译时，依赖 1.0.0 版本的 dep1

[target.x86_64-unknown-linux-gnu.release.dependencies]
  dep1 = "2.0.0"  # linux-x64 平台不以 debug(-g) 模式进行编译时，依赖 2.0.0 版本的 dep1

[target.x86_64-w64-mingw32.dependencies]
  dep1 = "3.0.0" # windows-x64 平台编译时（无论是否为 debug），依赖 3.0.0 版本的 dep1

注意：

• target 指定的平台名可在对应平台上通过命令 cjc -v 获取；
• target 中指定的依赖项若与非平台隔离的同类依赖项冲突，cjpm 将会报错。

依赖冲突处理

使用中心仓制品的过程中，可能存在依赖冲突的情况，此时可通过如下方式尝试解决：

• 依赖其他功能类似的中心仓模块，避免依赖冲突；
• 调整依赖项的版本范围，包含更多可用版本，从而提高搜索到可用版本的可能性；
• 若编译过程中涉及到多个本地模块，请检查这些模块之间是否有依赖冲突；
• 使用 cjpm update 命令，更新本地索引缓存，以获取中心仓上最新的制品信息。

当发生不可避免的版本冲突时，cjpm 依赖解析将会失败。例如，本地有如下项目结构：

demo
├── pro1
│    ├── src
│    │    └── pro1.cj
│    └── cjpm.toml
├── pro2
│    ├── src
│    │    └── pro2.cj
│    └── cjpm.toml
├── src
│    └── demo.cj
└── cjpm.toml

其中，三个模块的配置如下：

# demo/cjpm.toml
[dependencies]
  pro1 = { path = "./pro1" }
  pro2 = { path = "./pro2" }

# demo/pro1/cjpm.toml
[dependencies]
  dep1 = "1.0.0"

# demo/pro2/cjpm.toml
[dependencies]
  dep1 = "2.0.0"

模块 demo 依赖了本地模块 pro1 和 pro2，但这两个本地模块对中心仓模块 dep1 的版本要求有冲突，cjpm 编译 demo 时会因为依赖冲突失败。

针对这一情况，cjpm 提供了 replace 字段，用于强制指定依赖项，其格式与 dependencies 相同，但在强制指定中心仓依赖项时，只能指定单一版本号。例如，demo 模块中进行如下配置：

# demo/cjpm.toml
[dependencies]
  pro1 = { path = "./pro1" }
  pro2 = { path = "./pro2" }

[replace]
  dep1 = "3.0.0"

进行上述配置后，尽管 pro1 和 pro2 分别依赖了 dep1 的 1.0.0 和 2.0.0 版本，由于 replace 的配置，最终都会强制依赖 3.0.0 版本的 dep1。

安装中心仓可执行程序

编译产物类型不为 executable 的中心仓模块只能被添加为依赖项，而编译产物类型为 executable 的中心仓模块还能通过 cjpm install 命令编译成可执行程序并安装到本地。在中心仓官网的制品页面，可以通过是否有 install 说明来确认该制品包是否可以通过 install 命令安装：

上述制品包可以通过如下命令安装到本地：

cjpm install cangjie_repository_artifact-1.0.0

基于仓库配置中配置的本地缓存路径 CACHE_PATH，本地安装目录为：

${CACHE_PATH}
├── bin               # 安装的可执行文件
│    └── cangjie_repository_artifact
└── libs              # 可执行文件所需的动态库，存放于以对应可执行文件名命名的目录中
     └── cangjie_repository_artifact
          └── ...

安装后，可以直接在命令行使用 cangjie_repository_artifact。如果可执行文件有需要的动态库，则在使用前还需要将对应路径添加到系统动态库环境变量中。