search

rust-lang / rfcs

RFCs for changes to Rust
https://rust-lang.github.io/rfcs/
Apache License 2.0
5.94k stars 1.57k forks source link

[Feature Request] compile time arguments #2785

Open elichai opened 5 years ago

elichai commented 5 years ago

Currently the closest thing to C's preprocessor conditional compilations we have is the cfg and the features.

But there's one missing piece, and that's and that's values in those variables.

Currently the design idea of features is to be incremental which doesn't make sense with having values in those features. The thing is that in practice a lot of crates don't really use features as incremental and have mutually exclusive features.

I understand that the incremental features idea is rooted pretty deep in cargo's dependency resolvement. Is there a way to have this without a big problem with having the same dependency twice in the dependency graph but with different values? Could we maybe have some symbol randomness and just treat them as two different libraries?

jhpratt commented 5 years ago

Allowing multiple versions of the same crate inherently leads to very large binary sizes, if I understand what you're saying.

burdges commented 5 years ago

You can easily depend upon multiple versions with cargo-features = ["rename-dependencies"], which aids trait crate upgrades. In your case, you should maybe patch the dependency so that the two features work together.

elichai commented 5 years ago

Allowing multiple versions of the same crate inherently leads to very large binary sizes, if I understand what you're saying.

LTO should solve most of this. and that should be a decision left to users.

You can easily depend upon multiple versions with cargo-features = ["rename-dependencies"], which aids trait crate upgrades. In your case, you should maybe patch the dependency so that the two features work together.

That doesn't help. and you can't always "patch the dependency so that the two features work together". sometimes things inherently require arguments. i.e. size of constant arrays/tables for a lot of algorithms optimizations. there's a big tradeoff between size of binary and speed. which should be left up for the users (i.e. running in a server probably wants the later and in embedded want the former)