Looking at some crates in https://crates.io/ I found that rand is the most downloaded crate and looking in it's dependencies I found the libc crate and in it's dependencies I found the rustc-std-workspace-core which has 0 dependencies
with this description: "Explicitly empty crate for rust-lang/rust integration". I could not totally undestand what it means. Can someone explain in more details?
std depends on the libc crate.
Being a dependency of std is... not easy. The way std is built is complicated, it is tightly coupled with the compiler and built with it twice, for bootstrapping.
You can see this dependency is only activated if the rustc-dep-of-std feature is enabled.
This dependency allows std to depend on crates.
See also Plan for removal of rustc-dep-of-std.
Related
I build my rlib with cargo build —-lib. However when I use it with rustc main.rc —-extern mylib=mylib.rlib, I got an compile error can’t find crate for xxx which mylib depends on.
How could I get a rlib with all dependencies included?
How could I get a rlib with all dependencies included?
You can't. An .rlib file is the result of compiling one crate.
What is the correct way to sharing compiled library across projects then?
The Rust toolchain is not designed to support this in general.
One of the main reasons for this is that libraries have Cargo features which define whether certain conditionally-compiled code should be enabled or not, and libraries of the same major version are expected to not be duplicated. Putting these properties together means that you can't expect that compiling a library and its dependencies separately will produce a correct result (because some of the included dependencies might be missing features required by the separately compiled dependent, but must not be duplicated) — compilation needs to look at the entire graph of library crate dependencies.
You can share the cost of compiling one library to be used by another set of packages by putting all those packages in one workspace, but workspaces are designed for compiling a set of closely related packages and are not necessarily suitable for combining arbitrary ones.
I come from a Java background and have recently started with Rust.
The official Rust doc is pretty self-explanatory except the chapter that explains Crates and Packages.
The official doc complicates it with so many ORs and ANDs while explaining the two.
This reddit post explains it a little better, but is not thorough.
What is the exact difference between a Crate and Package in Rust? Where/When do we use them?
Much thanks!
Crates
From the perspective of the Rust compiler, "crate" is the name of the compilation unit. A crate consists of an hierarchy of modules in one or multiple files. This is in contrast to most "traditional" compiled languages like Java, C or C++, where the compilation unit is a single file.
From the perspective of an user, this definition isn't really helpful. Indeed, in most cases, you will need to distinguish between two types of crates:
binary crates can be compiled to executables by the Rust compiler. For example, Cargo, the Rust package manager, is a binary crate translated by the Rust compiler to the executable that you use to manage your project.
library crates are what you'd simply call libraries in other languages. A binary crate can depend on library crates to use functionality supplied by the libraries.
Packages
The concept of packages does not originate in the Rust compiler, but in Cargo, the Rust package manager. At least for simple projects, a package is also what you will check into version control.
A package consists of one or multiple crates, but no more than one library crate.
Creating packages
to create a new package consisting of one binary crate, you can run cargo new
to create a new package consisting of one library crate, you can run cargo new --lib
to create a package consisting of a library as well as one or multiple binaries, you can run either cargo new or cargo new --lib and then modify the package directory structure to add the other crate
When should you use crates, and when should you use packages?
As you can see now, this question doesn't really make sense – you should and must always use both. A package can't exist without at least one crate, and a crate is (at least if you are using Cargo) always part of a package.
Therefore, a better question is this:
When should you put multiple crates into one package?
There are multiple reasons to have more than one crate in a package. For example:
If you have a binary crate, it is idiomatic to have the "business logic" in a library in the same package. This has multiple advantages:
Libraries can be integration tested while binaries can't
If you later decide that the business logic needs to also be used in another binary, it is trivial to add this second binary to the package and also use the library
If you have a library crate that generates some files (a database engine or something like that), you may want to have a helper binary to inspect those files
Note that if you have a very big project, you may instead want to use the workspace feature of Cargo in these cases.
If my library is declared as no_std, can I use std for my integration tests, or could that implicitly change something in the library? I found this similar question, which implies that using std is ok in such a situation, but it doesn't explicitly answer my question.
Does the answer to my question change if I'm using build-std for a custom target instead of a prebuilt std library?
No, your library will not be affected by the crates that depend on it. That would be a horrible world.
I want to completely eliminate the dependency on std in my project so I disable the std feature in extern crates.
Somehow the final product is still linked to std, so I want to figure out which external crate is causing the linkage to std.
For standard shared libraries, this can be accomplished with ldd, but according to file, the rlib files in the deps directory are ar archives.
You can use cargo tree to get a tree graph of all the dependencies and sub-dependencies of your project. Then you can find out which crate requires std, and potentially look for solutions/alternatives.
If I find a crate I'd like to use, how can I find out with which versions of Rust the crate works as expected?
Right now, you either read the crate's documentation or test it yourself. Many larger crates test against an older pinned version of Rust in CI when they make a stability claim.
There is a proposed RFC that would add the Rust version to the Cargo.toml file.