如何使用 Cargo 将库构建为 rlib 和 dylib 但内容不同?

问题描述

我想做一个包含以下内容的项目:

I would like to make a project that contains:

• 图书馆
• C 的绑定
• 使用库的可执行文件

目录结构，不包括临时文件和其他垃圾:

The directory structure, excluding temporary files and other trash:

.
├── Cargo.toml
├── src
│   ├── c_bindings.rs // contains C bindings for library
│   ├── compression.rs
│   ├── const_data.rs
│   ├── hash.rs
│   ├── lib.rs // library
│   └── main.rs // simple executable that uses library
└── target
    └── debug
        ├── gost_stribog
        ├── libgost_stribog.rlib

我希望 cargo build 这样做:

• 构建将忽略 c_bindings.rs
的 Rust 库 (rlib)
• 将使用 c_bindings.rs
的 C 库 (dylib)
• 可执行

调试目录应该是:

└── target
    └── debug
        ├── gost_stribog
        ├── libgost_stribog.rlib
        ├── libgost_stribog.so

我的 Cargo.toml 应该是什么样的?

What should my Cargo.toml look like?

推荐答案

有意见的答案:不要.

相反，将您的代码分成两个或三个单独的包:

Instead, split your code into two or three separate crates:

1. 核心库.
2. 库的 C 绑定.
3. (可选)可执行文件.

然后，将您的 c_bindings.rs 移动到 bindings crate，就像 lib.rs 一样.它可以依赖于核心库.您还可以将 main.rs 移动到另一个同样依赖于核心库的 crate 中.

Then, move your c_bindings.rs to the bindings crate as just lib.rs. It can depend on the core library. You can also move main.rs into another crate that also depends on the core library.

这三个 crate 可以在同一个源代码存储库中，但将使用单独的调用构建.

These three crates can be in the same source code repository, but will be built with separate invocations.

货物工作区证明是有用的；事实上，它被列为一个明确的原因(带有用于 FFI 绑定的子板条箱的 FFI 板条箱").

A Cargo workspace may prove to be useful; in fact it's listed as an explicit reason ("An FFI crate with a sub-crate for FFI bindings").

这篇关于如何使用 Cargo 将库构建为 rlib 和 dylib 但内容不同?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！