What's the right way to apply a patch to a vendored dependency in the rustc source tarball?
If I directly modify it, I have to update the checksum file, which is fragile and will break every version.
If I use a [patch] entry in Cargo.toml, it needs to regenerate the lockfile, and so frozen breaks it.
(The context is https://android.googlesource.com/toolchain/android_rust/+/refs/heads/master/patches/rustc-0005-Remove-special-cased-darwin-compiler-rt-support.patch which probably doesn't make sense to actually upstream, since it is only needed due to a quirk of our build environment)
If you add a
[patch] entry in
Cargo.toml, you can run
cargo fetch. It is meant to download all dependencies from the internet when necessary, but it has the side effect of updating
Cargo.lock for changes to
Cargo.toml. It is a bit of a hack, but it should work.
Ah yeah, so I can have a patch which adds a
[patch] entry to
Cargo.toml, then run
cargo fetch --offline to fixup. This seems to almost work, but the
.cargo/config that replaces crates-io with a vendored copy only appears during the execution of
bootstrap.py, and without it cargo fetch will attempt to actually fetch sources and fail.
I can work around this in my build script by running
x.py --help, expecting failure, and then running
cargo fetch --offline, but this does seem a little icky. I don't see any user facing way to trigger the
.cargo/config generation otherwise though
In Fedora, I just clear the files list in
.cargo-checksum.json. An empty list always passes validation. :)
@cuviper I think I like the patch approach a little better anyways, since it might allow us to add incremental support to our presubmit checks for this project someday, but I'll keep it in mind, thanks.
@cuviper Debian nukes the checksum file as well, for the same reason.