Closed dr-orlovsky closed 2 years ago
I'm not following. The issue mentions the breaking changes being reverted. Is this still not fixed in the later release?
Assuming this is the case, I think the better solution would be to replace your own dependency with a patch, assuming this will eventually be fixed in the cmake crate. Otherwise this would force the cmake crate version to be exactly "0.1.43" for all the crates using zeromq-src
in their dependency tree, since from what I recall, cargo forces one major version per crate, which could lead to problems.
Is this still not fixed in the later release?
They are not. They have new release once a year or so...
better solution would be to replace your own dependency with a patch, assuming this will eventually be fixed in the cmake crate
that's exactly what I did
Otherwise this would force the cmake crate version to be exactly "0.1.43" for all the crates using zeromq-src in their dependency tree, since from what I recall, cargo forces one major version per crate, which could lead to problems.
True, but if we follow your suggestion it will mean that the crate is simply broken for everyone, and the patch is a solution just for a single project. Also, with the patch, it will be impossible to publish downstream crates to crates.io - and taking into account the release cycle for cmake-rs this may last for many months.
Not needed anymore since we have #17 for now
check https://github.com/alexcrichton/cmake-rs/issues/96 for details