In a Rust crate, is it possible to invoke a build.rs only for release mode?
One can specify it in Cargo.toml:
[package]
build = "build.rs"
The issue is, for development, it delays the beginning of compiling the crate's sources. The Cargo guide doesn't seem to offer such an option.
You can use this build script. Cargo passes PROFILE environment variable to rustc invokation, which can be used to determinate active profile.
// build.rs
use std::env;
pub fn main() {
if Ok("release".to_owned()) == env::var("PROFILE") {
panic!("I'm only panicking in release mode")
}
}
Related
I'm new to rust. I'm following a getting started tutorial that imports the crate random-number but when running the code I'm getting the error can't find crate for 'random_number'. What am I doing wrong?
~/Cargo.toml:
[package]
name = "test"
version = "0.0.1"
edition = "2021"
[dependencies]
random-number = "0.1.8"
~/src/main.rs:
extern crate random_number;
use random_number::random;
fn main() {
let num: i8 = random!(..);
println!("{}", num);
}
rustc is not meant to be used directly. It is the compiler that can compile a .rs file, but it doesn't have any dependency manager attached to it. So if you decide to use rustc directly, you need to manage your dependencies manually.
cargo is the official tool to compile Rust projects. It internally uses rustc, but additionally manages the project's dependencies that are specified in Cargo.toml.
cargo build --release && ./target/release/<project_name>
or the short form:
cargo run --release
If I build my project with
cargo build --verbose --target=i686-linux-android
where build.rs looks like this
fn main() {
#[cfg(target_os = "linux")]
{
panic!("target_os is linux!!!!!!!!!!!!!");
}
I get the panic at panic!("target_os is linux!!!!!!!!!!!!!");, but the target is android.
Why?
The build.rs script is compiled and run locally and thus its #[cfg(...)] attributes will reflect the local system. If you want to know the operating system that you're ultimately building for, use the CARGO_CFG_TARGET_OS environment variable.
Others can be seen in Environment variables Cargo sets for build scripts in the Rust Reference.
I have a procedural macro crate Proc and binary crate Bin. Bin has a dependency on Proc. Proc needs a filled environment variable to function properly.
This is some code inside my build.rs in Bin. Proc can successfully find the env value when using the following code:
fn main() {
println!("cargo:rustc-env=SOME_ENV_VALUE=somevalue");
}
However, Proc fails to find the environment variable when using this code inside my build.rs in Bin (note: when checking the existence right after the dotenv call, I can verify the key is actually present):
fn main() {
dotenv::dotenv().unwrap();
}
This is my Proc crate:
use proc_macro::TokenStream;
#[proc_macro_derive(MyProcMacro)]
pub fn my_proc_macro(input: TokenStream) -> TokenStream {
if std::env::var("SOME_ENV_VALUE").is_err() {
panic!("Failed to retrieve env value")
}
TokenStream::new()
}
Why won't it fail with the println! command? Can it work with dotenv? Else I need to write some code that copies the keys from my env file to the println! command...
All the code is in my minimal reproduction project.
I encourage you to re-read the Build Scripts chapter of the Cargo docs. A build script is a separate executable that Cargo builds and executes before starting to build your source code.
Cargo starts
Cargo executes rustc to build the build script
Cargo executes the build script
Cargo executes rustc to build your code
Cargo exits
[dotenv] loads environment variables from a .env file, if available, and mashes those with the actual environment variables provided by the operating system.
Variables that it loads are placed into the current processes environment variables. In your example, that's the build script executable.
[cargo:rustc-env] tells Cargo to set the given environment variable when compiling the package
The stdout of the build script interacts with Cargo, which then modifies how the code is compiled, including what environment variables to set.
You need to load the dotenv file and set the environment variables for the subsequent compilation. Something like this compiling-but-untested example:
fn main() {
if let Ok(env) = dotenv::dotenv_iter() {
for (k,v) in env.flatten() {
println!("cargo:rustc-env={}={}", k, v);
}
}
}
Don't worry that this method is marked as deprecated. The maintainers changed their minds.
I am using some Rust unstable features, but I still want to be able to compile a reduced version of my library with stable Rust. I am happy to only include those unstable features when the compiler supports them, and exclude them when they are not supported.
I thought it would be easy to achieve this goal using conditional compilation like #[cfg(rust_version = "nightly")], but it seems like 'stable' vs 'nightly' are not cfg options.
How do you guys perform conditional compilation based on 'stable' vs 'nightly', or based on the compiler version?
I recommend creating a feature for your nightly-only code that is disabled by default, for example
Cargo.toml
[features]
default = []
nightly-features = []
Since the nightly-features feature is not default, compilation with the stable toolchain works out of the box. You can use attributes #[cfg(feature = "nightly-features")] and #[cfg(not(feature = "nightly-features"))] to include or exclude code from nightly-specialized versions. This method has the added benefit of allowing testing of the nightly features independently of the compiler (i.e. answer the question: did the compiler break my code, or does code enabled by nightly-features contain bugs?).
Despite the risks, I want to enable nightly features automatically
Use build scripts, sometimes called build.rs in addition to the nightly feature described above. (note: the following should NEVER be used in a library, otherwise switching compilers could become a breaking change. prefer the solution explained above)
build.rs (goes in package root)
use std::env;
fn main() {
let rust_toolchain = env::var("RUSTUP_TOOLCHAIN").unwrap();
if rust_toolchain.starts_with("stable") {
// do nothing
} else if rust_toolchain.starts_with("nightly") {
//enable the 'nightly-features' feature flag
println!("cargo:rustc-cfg=feature=\"nightly-features\"");
} else {
panic!("Unexpected value for rustc toolchain")
}
}
this build script checks the toolchain environment variable set by rustup (some rust installations do not use rustup) and enables the nightly feature flag if the compiler is nightly.
src/main.rs
fn main() {
#[cfg(feature = "nightly-features")]
println!("Hello, nightly!");
#[cfg(not(feature = "nightly-features"))]
println!("Hello, stable!");
}
now, running
➜ cargo +stable run
Hello, stable!
➜ cargo +nightly run
Hello, nightly!
Is it possible to turn this feature off when build.rs turns it on?
As far as I can tell, no. Running cargo +nightly run --no-default-features leaves the feature on, due to how cargo passes flags to rustc. A programmer could create a specific environmental variable that build.rs checks for to skip the automatic version detection, but that is more complicated than the alternative with no build script - cargo build --features=nightly-features
Crate alternative
Instead of the proposed solution, you can use the rustversion crate, which works in a very similar way (but parses the output of rustc --version).
fn main() {
#[rustversion(nightly)]
println!("Hello, nightly!");
#[rustversion::not(nightly)]
println!("Hello, stable! (or beta)");
}
I try to compile my project with the command cargo build.
build.rs
extern crate csv;
use std::path::Path;
use std::fs::OpenOptions;
use std::io::BufWriter;
use std::io::Write;
#[allow(non_snake_case)]
fn processCSV(filename: &str, sourcePath: &str, enumName: &str) {
println!("Generate rust source code from schema {}",filename);
let mut ret: Vec<String> = Vec::new();
let mut rdr = csv::Reader::from_file(filename).unwrap().flexible(true);
for record in rdr.records().map(|r| r.unwrap()) {
}
let path = Path::new(sourcePath);
let file = match OpenOptions::new().write(true).create(true).open(&path) {
Ok(file) => file,
Err(..) => panic!("Cannot create file {}",path.display()),
};
let mut writer = BufWriter::new(file);
writer.write_all(b"test\n");
}
fn main() {
processCSV("../schemas/Test.csv", "./src/mod/common/StatusCode.rs", "StatusCode");
}
and Cargo.toml
[package]
name = "rust-test"
version = "0.0.1"
build = "build.rs"
[lib]
path = "src/lib.rs"
[dependencies]
[build-dependencies]
csv = "*"
I can see this error :
src/lib.rs:1:1: 1:18 error: can't find crate for csv
src/lib.rs:1 extern crate csv;
but when I change flexible(true) to flexible(false) it compiles just fine without any errors. What do I need to do to fix this?
I am using Rust 1.2.0 on Windows 7 64-bit.
Changing flexible(false) for flexible(true) makes no difference for me; both fail. The problem is that you've chosen build-dependencies for some reason, instead of just dependencies.
Using the src/lib.rs file that you provided in your answer, and this Cargo.toml file:
[package]
name = "stack-overflow"
version = "0.1.0"
authors = ["A. Developer <a.developer#example.com>"]
[dependencies]
csv = "*"
It compiles fine.
If you need to access a dependency both in your build.rs and in your project, you need to include the dependency in both sections.
A build dependency is a dependency for a build script, which is a helper binary compiled and run before your main crate is built (designed to be used for code-generation, and building/finding native C libraries, etc.).
Normal dependencies used by the main code should just fall into the "dependencies" section, e.g.
[dependencies]
csv = "0.14"
There's also a "dev-dependencies" section, which are dependencies that are only needed for testing, i.e. they are compiled and used only for cargo test. This allows crates to depend on, for example, quickcheck for running tests without contaminating the main artifact.
In summary, running cargo build will do something like:
build any build-dependencies
build the build script (pointing the compiler to the built build-dependencies), and run it
build any dependencies
build the main crate (pointing the compiler to the built dependencies)
Running cargo test adds:
build any dev-dependencies
build the main crate with --test to create a test runner for any in-source #[test]s (pointing the compiler to both the dependencies and dev-dependencies)
build any external examples or tests, also pointing to both the dependencies and dev-dependencies