Sometimes it can be useful to disable certain extensions even if the host cpu sports them. - [x] Refactor the cached check logic in `src/detect/mod.rs` - [x] Add a `RUST_STD_DETECT_DISABLE` `env::var` check - Takes a space separate list of strings - For each of them mapping to an arch Feature, turn it off. - [x] Document its existence @gnzlbg Do you see any problem in this approach?
Activity
gnzlbg commentedon Sep 2, 2019
Shall this env variable be read at run-time, or at build time ?
Either way, I think enabling this should be put behind a cargo feature that's disabled by default.
bjorn3 commentedon Sep 2, 2019
I think it should be during runtime, so you dont have to recompile the world.
lu-zero commentedon Sep 2, 2019
run-time
Not sure how to name the feature. (and how to advertise it)
bjorn3 commentedon Sep 2, 2019
allow-runtime-detect-override?lu-zero commentedon Sep 2, 2019
I'm sold on it, now, which crate should expose it?
lu-zero commentedon Sep 2, 2019
Also: should we make the cpu feature checks macro behave like log?
gnzlbg commentedon Sep 6, 2019
Maybe
std_detect?There is an RFC that allows something like that: rust-lang/rfcs#2725 but I'm not sure if that's what you mean.
lu-zero commentedon Sep 8, 2019
It is exactly what I meant.
Also this use-case might be mentioned here
I'll start sending the refactoring patches and the initial impl soon.
lu-zero commentedon Sep 9, 2019
I started with #806
Where should I put the documentation about the env variable?
Can I use this to implement the mapping
name -> featuremapping?Override the features detected using an env::var
Override the features detected using an env::var
Override the features detected using an env::var
Override the features detected using an env::var