> [replace] section to Cargo.toml of libgkrust pointing to the edited > crate under third-party/rust or adding paths = [ "third-party/rust" ] > to .cargo/config.in don't make Cargo happy.
[replace] is the way to do it, but it has to point to a crate outside of the vendoring directory. The vendor directory is like ~/.cargo; it's not supposed to be edited by anything other than the tool. -Manish Goregaokar On Sun, Feb 26, 2017 at 9:51 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > I tried to add some panics to a vendored to create (rust-encoding) to > see if the code in question runs. However, I didn't get to the running > part, because the edited code failed to build. > > It turns out that each vendored crate has a .cargo-checksum.json file > that contains hashes of all the files in the crate, and Cargo refuses > to build the crate if the hashes don't match or the > .cargo-checksum.json file is removed. > > This seems hostile not only to experimental local edits as in my case > but also to use cases such as uplifting fixes to branches and shipping > modified crates if the upstream is slow to accept patches or disagrees > with the patches. > > As far as I can tell, there doesn't seem to be a way to ask cargo to > regenerate the .cargo-checksum.json after edits. Also, adding a > [replace] section to Cargo.toml of libgkrust pointing to the edited > crate under third-party/rust or adding paths = [ "third-party/rust" ] > to .cargo/config.in don't make Cargo happy. > > What's the right way to build with edited crates under > third-party/rust? (I think we should have an easy way to do so.) > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
