make sure build.rs is re-run, when env vars change #694
Conversation
librocksdb-sys/build.rs
Outdated
| Some(_) => "static", | ||
| None => "dylib", | ||
| let mode = match env::var(&format!("{}_STATIC", lib_name)).as_ref().ok().map(|s| s.as_str()) { | ||
| Some("") | Some("true") | Some("1") | Some("static") => "static", |
There was a problem hiding this comment.
- Does it really make sense to check all these variants? What if I set
ROCKSDB_STATIC=yes? - Why do you use
env::varwith.ok()rather thanenv::var_os?
let mode = match env::var_os(&format!("{}_STATIC", lib_name))
.as_ref()
.and_then(|s| s.to_str()) {
...?
There was a problem hiding this comment.
Will change to var_os, I wasn't aware of the internal implementation of https://doc.rust-lang.org/src/std/env.rs.html#236 fn var.
Will also add yes as an enabling value.
The idea to accept only specific names or empty, is to allow the inverse usage as well: ROCKSDB_STATIC=false is something that is intuitive, when ROCKSDB_STATIC=1 enables static linkage.
If you don't want to link statically just unset env variable. So. I'd leave logic of working with env variable |
|
I did a brief survey, and the dependencies are less coherent than I expect, tbh it's a mess. https://github.com/rust-lang/libz-sys/blob/main/build.rs#L25 Hence, I don't care about the solution, it'd be nice to have the duality that at least some references above exhibit in regards to value Note that with the current change, the current behavior of having an |
|
I think that changing the |
Currently a change in linkage mode env vars will not trigger a re-run of the
build.rs-binary, and hence compilations fail until the that binary is deleted or other triggers are manually triggered.To my understanding, it's a mere lag of 3 lines telling cargo to re-run the build script on env var change.
Also adds the option to NOT link statically if i.e.
ROCKSDB_STATIC=falseis provided