cbindgen ignores version/don't parse depedency flag when selecting crates to expand which can make it unusable in certain situations about cbindgen HOT 9 OPEN

Could be easier and may "just" need to check the manifest_path

from cbindgen.

We have disabled parsing for dependencies but the flag is not considered either (it would be fine for us if it took it into account)

what happens in this case? what flag isn't considered?

from cbindgen.

We set parse_deps to false, but as the bug is happening in the way candidate crates are derived from the cargo metadata I believe it has no discernable effect

from cbindgen.

that sounds like a bug. Couldn't we fix this behavior? The dependency should get excluded if parse_deps: false or if it's listed in excluded

from cbindgen.

Well the actual bug is parsing metadata without checking the version IMO, but as indicated on the PR, I don’t know what the course of action should be on cbindgen side to determine the version of the crate to properly select it in the cargo metadata.

I was thinking about canonicalizing paths but it introduces potential panics and would likely break with complex and networked build systems

from cbindgen.

To be more precise, if a project has a dependency with the same name, cbindgen gets confused with the path to use, cargo metadata has two entries with the same name but normally different path and versions, as it’s a hashmap we randomly pick the right crate.

One possibility is the manial version filter I proposed (as automating it with cbindgen looks non trivial), the other is based on path but introduces potential issues.

from cbindgen.

Basically cbindgen does not even realize it's parsing a dependency as it's relying on the name to know if it's the main project

from cbindgen.

The cbindgen expand config could be modified to optionally accept a version number to match in addition to the package name. I’ve encountered this same issue on one of my own projects as well.

from cbindgen.

Yep tried that as first version the patch and I think that’s what we ended up shipping (or some path based thing to validate the manifest) in a fork for our use case

from cbindgen.