I have the following binary crate source structure:
prj
|
|__config
| |___conf.toml
|
|___src
| |_...
|
|__Cargo.toml
So when performing cargo run I expect the following command to run bin /path/to/prj/config/conf.toml.
Is it possible to config cargo run in Cargo.toml so it passes the absolute path to the config/conf.toml without passing it explicitly every time?
Is it possible to config cargo run in Cargo.toml so it passes the absolute path to the config/conf.toml without passing it explicitly every time?
Not exactly, but Cargo can be configured with command aliases in its configuration files. For example, you could place the following into ${PROJECT_ROOT}/.cargo/config.toml:
[alias]
runx = "run /path/to/config/conf.toml"
And then you'd just do cargo runx.
Related
A fantastic crate is cargo watch, which allows, for example, for you to execute:
cargo watch -x run
to automatically rebuild/run on src change. This is amazing for development but one issue I have is that it seems to not support the --manifest-path argument that can be used with cargo run to explicitly specify the path to the .toml file of the project such that it can be run from a different pwd than the Cargo.toml file itself:
cargo run --manifest-path /home/user/project/Cargo.toml
The crate documentation doesn't mention anything about this, so I was wondering if anyone who uses this crate has found a way around this. When attempting to use the --manifest-path argument I receive:
error: Found argument '--manifest-path' which wasn't expected, or isn't valid in this context
USAGE:
cargo watch [FLAGS] [OPTIONS]
Which makes some sense as I know not all commands support the --manifest-path arg, but since the crate uses cargo run to run the project itself I'm guessing there is some way around this without using e.g. sh -c 'cd [path to .toml file] && cargo watch -x run'
Yes you can just use the invocation which lets you run arbitrary commands:
cargo watch -- cargo run --manifest-path=path/to/Cargo.toml
I want to run tests with release optimisations using 1 test thread.
I can do these individually:
cargo test -- --test-threads=1
cargo test --release
How would I put these together?
You can use both in a single command like this:
cargo test --release -- --test-threads=1
How Cargo interprets these arguments ?
According to test subcommand's synopsis in reference :
cargo test [OPTIONS] [TESTNAME] [-- TEST-OPTIONS]
Cargo interprets input as :
Arguments before separator (--) will be used as an option for test subcommand. In your case cargo test accepts profile parameter as an option since it builds the project. Available options can be found under this title, or by running cargo test --help.
Arguments after the separator will be passed to the test binaries. In Rust project, Cargo uses rustc's libtest to run unit tests. In your case --test-threads=1 will be an argument for libtest.
This interpretation might not be valid for other subcommands, it is best to check other cargo commands from here. Checking synopsis section will give you a huge hint about capabilities of cargo's subcommands.
See also:
Since arguments after the dash will be sent to the rustc's libtest you can see available options for testing by: cargo test -- --help.
Profile options can be found under this title
I'm trying to run the example code from this project. Following the instructions on the Cargo docs, I did the following:
git clone https://github.com/basiliscos/rust-procol-ftp-client
cd rust-procol-ftp-client
cargo run
cargo test
cargo test should also have compiled the example according to the Rust docs.
Although cargo test executes successfully, when I change into the target/debug directory, I don't find an executable for ftp-get (which is the example code). The target/debug/examples directory is also empty.
What is the best way to go about running this example?
You can run a specific example with:
cargo run --example name_of_example
where name_of_example is the base filename (without .rs)
or to run it in release mode:
cargo run --release --example name_of_example
To pass arguments to the example:
cargo run --example name_of_example -- arguments go here
cargo run will automatically build (or rebuild) the program first if it's out of date.
Try the following:
cd rust-procol-ftp-client
cargo build --examples
./target/debug/examples/ftp-get
In a Cargo project, I can easily run clippy on my src code using this command:
rustup run nightly cargo clippy
However, if I'm using a build script, I'd like to run clippy on that as well. For instance, if my build.rs file looks like this:
fn main() {
let foo = "Hello, world!";
println!("{}", foo);
}
I'd like to see this when I run clippy:
warning: use of a blacklisted/placeholder name `foo`, #[warn(blacklisted_name)] on by default
--> build.rs:2:9
|
2 | let foo = "Hello, world!";
| ^^^
|
= help: for further information visit https://github.com/Manishearth/rust-clippy/wiki#blacklisted_name
The only way I can think of to run clippy on my build script is to copy it into a cargo new temporary project, run clippy, make my changes there, and copy back, but this is horribly inconvenient and quickly becomes infeasible when build dependencies and the like are added to the mix.
Is there a simpler way to analyze my build script with clippy?
Note: This solution no longer works. The clippy plugin feature has been removed (source).
There are two ways to use Clippy: the cargo clippy command and the clippy compiler plugin. cargo clippy detects the build script as a dependency of the main project, so it doesn't load the compiler plugin.
Therefore, the other option is to use the compiler plugin directly. The instructions for doing this are in clippy's README. We need to make a few adaptations for using it on the build script, though.
First, we need to add clippy as a build dependency:
[build-dependencies]
clippy = { version = "*", optional = true }
[features]
default = []
Adding it to [dependencies] instead will not work (the result is error[E0463]: can't find crate for `clippy`), as Cargo will not pass the path to dependencies to the compiler when building the build script.
Then, we need to add this at the top of build.rs:
#![cfg_attr(feature="clippy", feature(plugin))]
#![cfg_attr(feature="clippy", plugin(clippy))]
Finally, we need to build with the clippy feature enabled:
$ cargo build --features clippy
If you want to run clippy on both the build script and on the main project when you use the command above, add the same clippy dependency to [dependencies], then add the cfg_attr attributes to the crate root(s) (lib.rs, main.rs, etc.).
I'm new to Rust and I want to build and run my project. I use something like:
cd %project_path%
cargo run
I want to be able to write cargo run -path %project_path% in a single line because I want to create a build script that doesn't allow changing the working directory. It seems that cargo doesn't have any -path or -target keys, which would define target directory, and I always get the message
could not find Cargo.toml in C:\WINDOWS\system32 or any parent
directory
The --manifest-path path/to/Cargo.toml option to almost all cargo subcommands allows pointing it to a specific Cargo.toml file to use, overriding the default of searching the current directory and its parents for a file called Cargo.toml (this file is the "manifest").
Incidentally, unix-y commands usually take a -h or --help argument which prints information about their command line options, cargo and rustc are no exception. E.g.
$ cargo run --help
Run the main binary of the local package (src/main.rs)
Usage:
cargo run [options] [--] [<args>...]
Options:
-h, --help Print this message
--bin NAME Name of the bin target to run
--example NAME Name of the example target to run
-j N, --jobs N The number of jobs to run in parallel
--release Build artifacts in release mode, with optimizations
--features FEATURES Space-separated list of features to also build
--no-default-features Do not build the `default` feature
--target TRIPLE Build for the target triple
--manifest-path PATH Path to the manifest to execute
-v, --verbose Use verbose output
-q, --quiet No output printed to stdout
--color WHEN Coloring: auto, always, never
If neither `--bin` nor `--example` are given, then if the project only has one
bin target it will be run. Otherwise `--bin` specifies the bin target to run,
and `--example` specifies the example target to run. At most one of `--bin` or
`--example` can be provided.
All of the trailing arguments are passed to the binary to run. If you're passing
arguments to both Cargo and the binary, the ones after `--` go to the binary,