I have workspace and two particular crates in it: lib1 and lib2.
And lib2 depend on lib1. The problem is that when I run cargo build -p lib2 and then cargo build -p lib1 the rebuild happens.
I mean lib1 build during build of lib2 and then it rebuilds again after cargo build -p lib1.
My only idea is features, I mean the one of dependency of lib1 should have feature set1,
when I run cargo build -p lib1 and feature set2 when build lib2, and feature set1 != feature set2.
But which one?
I try cargo +beta tree -e features -p for lib1 and lib2,
but I can not automate comparing of features set,
and manual checking is showing that they are the same.
May be I missing something, and for example cargo +beta tree -e features not work as expecting,
and doesn't show set of feature for particular crate, instead it shows feature set for whole tree?
I think this does come down to features, does lib2 use any features that are different from the default
feature set of lib1?
That is my question, why you asking me?
Directly in Cargo.toml of lib1 and lib2 - no, but indirectly who knows,
I can not find way how to get from cargo +beta tree the list, with crates and features instead of tree,
to run just diff to compare all dependicies.
I found way to get list: cargo +beta tree --prefix none, but looks like deps are the same. This drive me nuts, though I not completly sure, because of cargo tree print each feature on the new line,
instead of near crate name.
I found culprit: it is chrono and num-traits.
chrono use
num-traits = { version = "0.2", default-features = false }
while other dependency rstar use with default-features on.
But I am not sure what is really going on,
looks like:
[features]
default = ["std"]
std = []
i128 = []
And I build std code anyway, why cargo think that num-traits = default = false, and num-traits = deafult = true is the different thing?
For std build it should be the same thing?
Cargo doesn't know anything special about that "std" feature, and treats it just like any other. So in building one of the libraries, it sees a subset of crates that include num-traits without default features, so it builds without. In your other library it sees num-traits required with default features enabled, so it does.
One way to see this is cargo build --verbose, and look for --cfg for the feature. I agree it would be nice to get cargo tree to show this though.