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. > Can you elaborate on what goes wrong here? This worked for ted's experiment mentioned upthread, and for me on at least one occasion in https://hg.mozilla.org/try/rev/18dc070e0308 (permalink: https://pastebin.mozilla.org/8980438 ) You'll need to |cargo update| after adding the replace in Cargo.toml to update Cargo.lock. > > 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
