RLib — A zero-overhead precompiled crate manager to reduce compile times and disk usage

help
1

Hello, I wanted to share a tool I’ve been creating on called RLib to gather feedbacks. It’s a lightweight, zero-overhead development helper designed to precompile crates (like tokio, serde, etc.) and seamlessly share them dynamically across all local workspaces.

Why built this?

We've all been there: every time we spin up a project or run cargo clean, the machine spends minutes re-compiling the exact same dependencies from scratch, bloating SSD storage with duplicate gigabytes in every single target folder.

Unlike caching tools like sccache which rely on compression/decompression algorithms (introducing small time costs when unpacking artifacts), RLib uses a zero-overhead approach. It directly binds and passes the global precompiled binaries into the development workspace via custom path and compiler flag.

Key Features:

  • Universal Reuse: Compile dependency once (~/.rlib), use it everywhere.
  • Save Massive Disk Space: Stops standard dependency duplication across multiple project folders.
  • cargo clean Proof: The cached crates stay safe outside the workspace. Running clean will never wipe the precompiled dependencies unless we explicitly tell RLib to remove them.
  • Under-the-Hood Optimizations: Automatically leverages high-performance linkers (mold, lld) and alternative memory allocators (mimalloc, tcmalloc) seamlessly.

Quick Workflow Example:

  1. Initialize the project config:
rlib init
  1. Precompile crate (e.g., Tokio with full features):

Check if the crate is already on the global list

rlib list

If not there yet, then compile the crate

rlib tokio features=full
  1. Check the global list and copy the unique key:
rlib list
# Output: tokio_1_38_0_full
  1. Link it to the local workspace list:
rlib this add tokio_1_38_0_full
  1. Run the project instantly:
rlib this cargo run
# Or for instant compilation checks:
rlib this cargo check

I'd love to hear your thoughts, feedback, or any edge cases you think I should look out for regarding on anything

Here is the project github : GitHub - fuji-184/RLib · GitHub

2

I would separate fn print_help() { body in a separate file and include it by include_str!. It simplifies localization and you can easily provide the help in Japanese, Chinese and other languages.

3

Note we should be stabilizing a new build-dir layout this week. We've also talked about moving build-dir out of target-dir by default.

4

Thank youu, I will separate it to different file, which one do you think is better and why? stack str or global &'static str?

5

Yeah, no problem. It will be quick to update the path to new build dir layout

6

Such string will always appear in the static segment, but you can add static to emphasize.

7

Yeah, I forgot I asked that in another post. Thank youu

8

Wow, this is the tool I didn't know I needed, I maintain large desktop apps using wxDragon, and having to manually redownload and build that every time gets super old. Thanks a ton for this, starred.

9

Thank youu. But there is still bug

I found a bug, if lib A uses tokio, and the project uses lib A and tokio again. The one that I found is

[dependencies]
axum (internally uses tokio)
tokio again

The tool passes double tokio to the compiler that causes the compilation fail. I'm still trying to fix it, the fix algorithm that I can think of currently is saving the list of internal libs that is used by the library, then comparing it to the libraries that is called directly in Cargo.toml, if there is same library, remove the internal version and only pass the one that is directly called in Cargo.toml to the compiler

If you can fix it faster please submit pull request :]

The library can also be a proof of concept that I hope will make better library exist that maintains zero overhead