The backtrace dependency always builds with features = ["gimli-symbolize"]

[pyrrho]

At the time of writing, Cargo intentionally unifies features before it prunes dependencies behind [build-dependencies], [target.'cfg(...)'.dependencies], and similar sections. See rust-lang/cargo#1197 and rust-lang/cargo#2524 for some discussion about that behavior. I also have a minimal demonstration of surprising unifications in a playground repo of mine.

This is a direct problem for me because I'm trying to write library code that can compile for both native targets (macos, windows, etc.) and WASM. The plan is to include color_backtrace only on non-WASM targets. It is, currently, impossible to compile backtrace with features = ["gimli-symbolize"] activated for WASM targets. (Why that is takes a bit of explaining; feel free to ask if you're curious.) That means if color_backtrace is anywhere in my dependency graph -- even pruned behind a [target.'cfg(not(target_arch = "wasm32"))'.dependencies] section -- "gimli-symbolize" will be activated for the build's backtrace dependency, and the compilation will fail.

One solution for my build failure, and something to consider for this crate generally, would be moving the "gimli-symbolize" activation from a target-specific dependency to a re-exported feature. Something like this,

[features]
default = []
optimize_for_unix = ["backtrace/gimli-symbolize"]

[dependencies]
backtrace = "0.3"

If I can't work-around this class of error in some other way, I'll likely open a PR with that change in the next few days.

[athre0z]

Thank you for this in-depth explanation of the issue!

I also noticed that Gimli is being compiled unconditionally before, but didn't think it would be too much of an issue. Unfortunately, on Linux and macOS, libbacktrace, the backend being used when gimli-symbolize is omitted, is bugged pretty badly, so we will definitely want to keep Gimli enabled by default.

I think it should be possible to implement your proposed solution, except that we would default the feature to being enabled. I will have to evaluate whether that works in Windows. However, given that the conditions didn't have any effect anyway, chances should be good.

[athre0z]

I gave it a shot on this branch, please let me know if that would in fact resolve your issue! It appears to compile fine on all platforms.

[pyrrho]

I think that's a good change, generally speaking. I didn't know about the libbacktrace issues, and with that knowledge... I agree that gimli-symbolize should be left on by default. And should probably be left on for windows systems, too, as I've not heard of any issues with color_backtrace on that platform.

Unfortunately for me, my core issue of unwanted feature unification definitely persists with this change. That's more of a Cargo issue than a color_backtrace issue, so I don't think it's worth impacting your general user for my wasm-specific corner-case.

And in some good news, I think I have found a pattern to work around these issues in Cargo.toml. With a bit of extra feature threading, I should be able to completely skip color_backtrace when I need to, and build without a broken libbacktrace for the general case.

[athre0z]

Alright, merged into master! Since this is unfortunately all we can do for now over here, I'll close this for now.