Rust如何引入源码作为依赖
问题描述
通常我们在rust项目中引入第三方依赖包时,会直接指定包的版本,这种方式指定后,Cargo在编译时会从crates.io这个源中下载这些依赖包。
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
j4rs = 0.15.3
比如这里我们就在项目中引用了j4rs
这个包,这个包的主要作用是可以实现从Rust代码中调用Java代码。
博主在使用这个包时发现,crates.io上发布的最新版本0.15.3
有bug,这个版本依赖了logback的新版本,而logback的新版本使用了Java 11进行编译。这就导致了j4rs 0.15.3
这个版本不支持Java 8。
于是博主在github上向作者提了issue,作者很快就做了修改,并更新到了github项目的master分支上。然而作者却没有向crates.io推送最新版本的包,我们想用最新版本就不能直接引用crates.io上的版本。
想要解决这个问题也很简单,我们可以直接引用源码作为依赖,主要有一下两种方式。
方式一
Cargo支持直接引用git最新版本的代码
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
j4rs = { git = "https://github.com/astonbitecode/j4rs" }
方式二
引用本地源码
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
j4rs = { path = "../j4rs/rust" }
当我们引用三方包的源码后,编译时Cargo也会根据三方包的Cargo配置编译这些三方包的源码,然后把编译的结果输出到本项目的target/[debug/release]/deps目录下,这样本项目就可以使用这些三方包了。
博主在引用j4rs
这个三方包时遇到了这个问题:release编译时,编译器提示,j4rs编译的输出命名冲突。
解决方法
查看j4rs
源码中的Cargo.toml
文件
[package]
name = "j4rs"
version = "0.15.4"
...
[badges]
travis-ci = { repository = "astonbitecode/j4rs", branch = "master" }
[lib]
name = "j4rs"
crate-type = ["rlib", "cdylib"]
path = "src/lib.rs"
可以发现crate-type
这里配置了两种编译结果crate类型。
crate类型
bin: 二进制可执行 crate,编译出的文件为二进制可执行文件。必须要有 main 函数作为入口。这种 crate 不需要在 Cargo.toml 中或 --crate-type 命令行参数中指定,会自动识别。
lib: 库crate。它其实并不是一种具体的库,它指代后面各种库 crate 中的一种,可以认为是一个代理名称(alias)。通常来讲,如果什么都不配置,默认指的是 rlib, 会生成 .rlib 的文件。
dylib: 会在编译的时候,生成动态库(Linux 上为 .so, MacOS 上为 .dylib, Windows 上为 .dll)。动态库是平台相关的库。动态库在被依赖并链接时,不会被链接到目标文件中。这种动态库只能被 Rust 写的程序(或遵循 Rust 内部不稳定的规范的程序)调用。这个动态库可能依赖于其它动态库(比如,Linux 下用 C 语言写的 PostgreSQL 的 libpq.so,或者另一个编译成 "dylib" 的 Rust 动态库)。
staticlib: 静态库。编译会生成 .a 文件(在 Linux 和 MacOS 上),或 .lib 文件(在 Windows 上)。编译器会把所有实现的 Rust 库代码以及依赖的库代码全部编译到一个静态库文件中,也就是对外界不产生任何依赖了。这特别适合将 Rust 实现的功能封装好给第三方应用使用。
cdylib: C规范动态库。与 dylib 类似,也会生成 .so, .dylib 或 .dll 文件。但是这种动态库可以被其它语言调用(因为几乎所有语言都有遵循 C 规范的 FFI 实现),也就是跨语言 FFI 使用。这个动态库可能依赖于其它动态库(比如,Linux 下用 C 语言写的 PostgreSQL 的 libpq.so)。
rlib: rlib 是 Rust Library 特定静态中间库格式。如果只是纯 Rust 代码项目之间的依赖和调用,那么,用 rlib 就能完全满足使用需求。rlib 实现为一个 ar 归档文件。rlib 中包含很多 metadata 信息(比如可能的上游依赖信息),用来做后面的 linkage。可以指定生成 rlib,但是一般没必要设置,因为默认 lib 就是 rlib。rlib 是平台(Linux, MacOS, Windows ...)无关的。
proc-marco: 这种 crate 里面只能导出过程宏,被导出的过程宏可以被其它 crate 引用。
具体解释
根据文档j4rs
设置的两种crate类型,rlib
表示rust本身定义的中间结果,如果rust代码互相引用,直接使用这种类型就可以。cdylib
是符合c标准的动态链接库,这种方式编译的结果可以被其他语言作为动态库使用。
当我们进行release编译时,Cargo会根据配置帮我们编译j4rs
这两种格式的目标输出。
这时Cargo就会提示我们输出了一个libj4rs.rlib
文件,又要输出一个libj4rs.so
文件,这两个库文件名字一样,冲突了。这会导致我们的代码在链接j4rs
时无法选择应该使用哪个库。
因此解决方法是:只要在j4rs
的源码里将Cargo.toml
文件中的配置crate-type = ["rlib", "cdylib"]
改为crate-type = ["rlib"]
就可以了。
热门相关:骑士归来 仗剑高歌 寂静王冠 明月照大江 豪门闪婚:帝少的神秘冷妻