-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
Problem
Specifying conditional dependencies using target.'cfg(debug_assertions)'.dependencies
does not work as expected (i.e. only building the dependencies when debug assertions are enabled) and instead always includes the dependencies. The same applies for cfg(test)
and cfg(proc_macro)
although dev-dependencies
can be used instead of cfg(test)
.
I guess it kind of makes sense that only cfg
-attributes that have something to do with a target work in this context however it is still very confusing and unexpected. Also, the documentation explicitly mentions that cfg(feature = ...)
doesn't work so I would expect everything else to work.
Steps
Using this Cargo.toml
[package]
name = "test"
version = "0.1.0"
authors = []
edition = "2018"
[target.'cfg(debug_assertions)'.dependencies]
color-backtrace = "0.3"
and compiling with cargo build --release
still compiles color-backtrace
.
Possible Solutions
- Clarify in the documentation that only
cfg
-attributes related to targets work in this context. In that case, it would be good to add another way to include dependencies only for debug or release builds e.g. usingprofile.dev.dependencies
. (This might be a good idea in any case). - Allow all
cfg
-attributes in the target context. The main problem why this currently doesn't work is that thecfg
values are taken fromrustc --print cfg
which always includesdebug_assertions
. One option would be to callrustc
using the correct attributes for optimization, crate type, etc. but this would require some changes as this is currently computed as part ofTargetInfo
which is independent of any flags related to profiles. Another option would be to fix thecfg
list at the uses where profile flags would be available. Although this is kinda hacky it would be fairly easy to do as there are only 5 uses of thecfg
list and they all have profile information available.
Personally I think solution 2 will always be a bit messy so it's probably best to add something like profile.dev.dependencies
instead. I would be happy to implement this if it sounds like a good idea.