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"]就可以了。

热门相关:骑士归来   仗剑高歌   寂静王冠   明月照大江   豪门闪婚:帝少的神秘冷妻