I have a binary Rust project which uses the workspaces to manage sub-crates.
Directory structure
/myapp
Cargo.toml
/src
/tests
test.rs
/crates
/printer
Cargo.toml
/src
myapp/Cargo.toml
[package]
name = "myapp"
[workspace]
members = ["crates/printer"]
Inside of test.rs I can compile extern crate myapp; to pull in the parts of the application that are exposed in src/lib.rs. This works as expected.
However, when attempting to compile extern crate printer; it errors that it cannot find it. I've confirmed that the printer package is correctly placed in the top-level Cargo.lock file.
How do I include my sub-crates into the /tests directory at the top level?
There's nothing special about workspaces or even the concept of tests. If you want to use a crate in Rust code, you have to add it as a dependency:
[dependencies]
printer = { path = "crates/printer" }
See also:
How to define test-only dependencies?
Related
I have a rust binary crate (well, it also has a lib.rs file for tests), and am trying to write a build script. This build script needs to generate a JSON file from a static rust object (custom struct crate::datatypes::ErrorMarkup) using serde, which gets imported by the binary crate. I know I could just reference the static object in the binary crate, but the binary crate must import a JSON file that may eventually come from some other source or may be modified between the build and run phases (i.e. the intent is to ship the built file and the JSON file).
How do I reference crate data types and functions from a build script?
Project structure:
- cargo.lock
- cargo.toml
- markup.json (target file)
- build.rs
- src
- main.rs
- lib.rs (exports)
- datatypes.rs
- tests
- verify.rs
I have tried both use pump_log_tool (my crate) and use crate::src and a billion other variations.
I understand this may be an issue due to build dependencies and runtime dependencies. Is there an obviously better way to achieve this goal?
A build script can't depend on the crate it builds
Cargo compiles build.rs into its own crate with its own dependencies. By making your build script depend on the crate it's building, you create a circular dependency that Cargo can't resolve.
Move the needed types to a different crate
The typical solution is to move the items that are (presumably) defined in datatypes.rs to their own, separate crate, which does not require a build script. (This is also a common pattern with procedural macros.) Your new project structure might look like
/
|- Cargo.toml
|- build.rs
|- src/
| |- lib.rs
| \- main.rs
|- pump_log_tool_types/
| |- Cargo.toml
| \- src/lib.rs
Then, in /Cargo.toml, create a workspace section and add the new crate:
[workspace]
# This is a path relative to the workspace root.
members = ["pump_log_tool_types"]
In pump_log_tool/Cargo.toml, add the pump_log_tool_types crate as both a normal dependency and a build dependency:
[dependencies]
pump_log_tool_types = { path = "pump_log_tool_types" }
[build-dependencies]
pump_log_tool_types = { path = "pump_log_tool_types" }
Now when you build pump_log_tool, the pump_log_tool_types crate will be built once and shared between the build script and the crate itself.
I need different parts of my project to use different versions of the same extern crate so I'm refactoring my Rust project to be divided into multiple packages via the workspaces system using this as a guide. Doing so is causing all my pub extern crate imports to not work.
This post is very similar to one I created very recently and then deleted - this version contains a minimal, complete, and verifiable example.
Here's my project structure
workspace_test/
root/
src/
main.rs
Cargo.toml
Cargo.toml
workspace_test/Cargo.toml:
[package]
name = "workspace_test"
version = "0.1.0"
authors = ["Phoenix <kahlo.phoenix#gmail.com>"]
[workspace]
members = [
"root"
]
[[bin]]
name = "root"
path = "root/src/main.rs"
workspace_test/root/Cargo.toml:
[package]
name = "root"
version = "0.1.0"
authors = ["Phoenix <kahlo.phoenix#gmail.com>"]
[dependencies]
time = "0.1"
workspace_test/root/src/main.rs:
pub extern crate time;
fn main() {
println!("Hello, world!");
}
This is also on github, so it can easily be cloned and cargo run'd.
This is the error:
error[E0463]: can't find crate for `time`
--> root/src/main.rs:1:1
|
1 | pub extern crate time;
| ^^^^^^^^^^^^^^^^^^^^^^ can't find crate
error: aborting due to previous error
error: Could not compile `workspace_test`.
In workspace_test/Cargo.toml you create a package with the binary root. If you execute cargo run, it runs the main.rs, but since you didn't state the dependencies in this manifest file, the error occurs. The dependency is only specified in workspace_test/root/Cargo.toml, which is not used at this point.
I assume you want to use the workspaces proposed by the RFC. You can create a workspace with virtual manifests, which must neither specify a [package] nor [[bin]], so just remove them. workspace_test/Cargo.toml now looks like this:
[workspace]
members = [
"root"
]
If you only have one executable, you can now pass the package: -p/--package
cargo run -p root
or specify the manifest path manually:
cargo run --manifest-path root/Cargo.toml
If root/Cargo.toml contains multiple targets, you can just append the --lib or --bin flags as usual. E.g. this would execute the abc-binary specified in workspace_test/root/Cargo.toml:
cargo run -p root --bin abc
I have a crate that is imported straight off of GitHub, as per Cargo's documentation:
[dependencies]
libfoo = { git = "ssh://git#github.com/me/libfoo", branch = "dev" }
[lib]
path = "src/rust/lib.rs"
name = "myprj"
crate-type = ["cdylib"]
Running cargo build works fine here, Cargo fetches libfoo and builds it in the ~/.cargo directory. When I try to use (import) it in lib.rs:
extern crate libfoo; //also tried foo
Cargo chokes:
error[E0463]: can't find crate for `libfoo`
--> src/rust/lib.rs:1:1
|
1 | extern crate libfoo;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
Interestingly, IntelliJ's Rust plugin does find the crate when I click on it in lib.rs – it navigates to the downloaded source in ~/.cargo...
In the dependency libfoo, the lib section of the Cargo.toml file is specified as:
[package]
name = "libfoo"
[lib]
name = "foo"
crate-type = ["cdylib"]
I have tried all permutations of libfoo and foo to see if Cargo is getting confused between the lib name and the package/directory name.
It also fails if I specify a local path to the dependency. (Cargo compiles the dependency but then claims not to find it when it is declared/imported in lib.rs.)
[dependencies]
libfoo = { path = "/Users/me/dev/libfoo" }
If I include a crate from git or the file system that has the same [lib] name as the [package] name, it works fine. So it appears the problem is with crates that have a have a library ([lib]) name that is different from the package ([package]) name.
If I remove the [lib] section from the dependency's Cargo.toml file, it works.
Update: if crate-type = ["cdylib"] is removed from libfoo, this works with foo imported. If that is there, I get the same error with extern crate foo;.
Cargo is interested in package names when it comes to dependencies, while the compiler (rustc) is interested in library names when it comes to loading their metadata and linking with them.
Let's take a look again at this Cargo.toml excerpt:
[package]
name = "libfoo"
[lib]
name = "foo"
Here, the package name is libfoo and the library name is foo.
When you want to declare a dependency on libfoo in your project, you need to write the package name (libfoo) in the [dependencies] table. For example:
[dependencies]
libfoo = { git = "ssh://git#github.com/me/libfoo", branch = "dev" }
This is what you already have, and it's correct.
However, when you want to import the library in your crate, you need to write the library name in the extern crate item, i.e.
extern crate foo;
How did I figure this out? First, I wrote libfoo in both Cargo.toml and the extern crate item, as you described. When I ran cargo build, I noticed that libfoo was built successfully, indicating that Cargo correctly resolved the dependency. But I also noticed that the compiler couldn't find libfoo, as you experienced.
I then inspected the command line passed to rustc by running cargo build --verbose. This is what I saw (irrelevant parts omitted):
Running `rustc [...] --extern foo=/[path]/target/debug/deps/libfoo-5cf876c5c8ac1bfb.rlib`
The --extern name=path argument tells rustc that the crate named name is located in path. The name here is foo, so we must write extern crate foo; in the code to reference it.
I have a crate with both src/lib.rs and src/main.rs.
main.rs is just using extern crate programname (which is lib.rs) and uses certain functions from lib.rs and it's submodules.
The documentation on linking says:
Pure-Rust dependencies are statically linked by default so you can use created binaries and libraries without installing Rust everywhere.
How can I change this behavior so a binary created from main.rs will be dynamically linked to library produced by lib.rs?
I've added the following to Cargo.toml
[lib]
path = "src/lib.rs"
crate-type = ["dylib"]
[[bin]]
name = "programname"
path = "src/main.rs"
But it does not compile and gives me errors like:
error: cannot satisfy dependencies so `std` only shows up once
help: having upstream crates all available in one format will likely make this go away
If I add "rlib" to lib section, it compiles, but the binary is not linked against libprogramname.so
I want to build a dynamic link library (dll).
My Cargo.toml currently looks like this:
[package]
name = "sample"
version = "0.1.0"
authors = ["author"]
[lib]
name = "main"
crate-type = ["dylib"]
[dependencies]
I use VS Code with the RustyCode plugin as my IDE on windows.
When I run the build command this builds into a sample.exe and main.dll.
I know I can run cargo build --lib to only build my lib target but I dont have access to this command inside VS Code (afaik).
Is there anyway to specify that I only want to build the lib target in my Cargo.toml file so I can use the VS Code build command which runs cargo build/cargo run?
Cargo builds files using convention over configuration approach. When it finds a main.rs it builds an executable, and when it encounters lib.rs it expects to build a library.
Calling your lib main managed to confuse Cargo. The only solution I managed to find is to either change name of your crate from name = "main" to name = "foo" (and then rename your main.rs into foo.rs) or to change its name to lib.rs, as you did.
Just figured it: Rename the src/main.rs to src/lib.rs and it only builds the lib target!