Skip to content

target.'cfg(debug_assertions)'.dependencies doesn't work as expected #7634

@benediktwerner

Description

@benediktwerner

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

  1. 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. using profile.dev.dependencies. (This might be a good idea in any case).
  2. Allow all cfg-attributes in the target context. The main problem why this currently doesn't work is that the cfg values are taken from rustc --print cfg which always includes debug_assertions. One option would be to call rustc using the correct attributes for optimization, crate type, etc. but this would require some changes as this is currently computed as part of TargetInfo which is independent of any flags related to profiles. Another option would be to fix the cfg 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 the cfg 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-configurationArea: cargo config files and env varsA-diagnosticsArea: Error and warning messages generated by Cargo itself.C-bugCategory: bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions