Chiaki, In case you're still having trouble, you might find this information useful: https://searchfox.org/mozilla-central/source/media/mp4parse-rust/README.md
I think Dzmitry's suggestion of pointing the patch to third_party/rust/glslopt should work, but I seem to recall having some issues doing that kind of thing with the Cargo.toml patch directive, which may work better with directly overriding the path on the dependency entry directly. On Wed, Jan 5, 2022 at 1:45 PM Dzmitry Malyshau <[email protected]> wrote: > You should be able to add a cargo override pointing to the very > third-party it's vendored in. > Try this in the root cargo toml (i.e. > "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/Cargo.toml"): > > [patch.crates-io.glslopt] > path = "third_party/rust/glslopt" > > Then `mach vendor rust` and you should be good to go. > > -Dzmitry > > On Wed, Jan 5, 2022 at 2:55 AM ISHIKAWA,chiaki <[email protected]> > wrote: > >> I need a help. >> >> I create patches for TB and test locally under Debian GNU/Linux. >> I use M-C/C-C tree for local TB build and testing. >> >> Background: I have to modify M-C portion of the code although I am >> interested in patching C-C TB code. >> The reason is that I apply rather strict compiler warning/error >> options, and I apply then to ALL the directories including M-C tree. >> (It is not entirely clear how I can change the per directory setting >> of compiler options. I basically override the default specification by >> passing compiler option flags to the CC and CXX commands.) >> >> Some code in M-C tree have issues with sign vs unsigned comparison and >> unused variable and they are deemed as compile-time errors with my >> strict compiler options, and thus I have to modify M-C tree portion a >> bit to avoid the issues. >> >> The build failure.: >> >> Since I updated the M-C/C-C source tree in late December (I have not >> for a few weeks), I got the following error during local build and >> cannot proceed. (Well, actually the issue in Q2 below popped up first.) >> >> error: the listed checksum of >> `/NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/glslopt/glsl-optimizer/src/util/blob.c` >> >> has changed: >> expected: 8f729846f66efc9c15485cc5fc24c6ec861fc1fecb2f652573f2a237d481b791 >> actual: 5d7fb6253f80f0fe4ff98d52a9b73fda6536007634e55a2b7cb7fd36b1e2d963 >> directory sources are not intended to be edited, if modifications are >> required then it is recommended that `[patch]` is used with a forked >> copy of the source >> >> Q1: My question is exactly which file should be changed and how the >> entry should look >> like? >> >> I think the file to change is the following >> File: >> >> /NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/glslopt/.cargo-checksum.json >> >> This has the checksum of blob.c >> (I wish the file has a new line after each checksum. It must have been >> autogenerated.) >> I wonder manual-editing of the said json file is the way to go. >> It seems there is a better way with this `[patch]' option. But HOW? >> >> There is also a file called >> /NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/glslopt/Cargo.toml >> >> >> Q2 >> >> Actually I encountered a similar checksum issue before and had patched >> the TOP-LEVEL Cargo.toml. That has probably hid the issue until >> December, but I had to back it out temporarily because I got the >> following error now. >> >> error: the lock file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/Cargo.lock needs >> to be updated but --frozen was passed to prevent this >> If you want to try to generate the lock file without accessing the >> network, remove the --frozen flag and use --offline instead. >> >> (I now backed out the Cargo.lock file modification due to this error, >> and I think this caused the manifestation of the checksum error in Q1 >> again.) >> >> QUESTION: Where on earth does one specify "--offline" instead of >> "--frozen"? >> >> Any tips regarding these two issues will be appreciated. >> >> I am afraid that mozilla documentation is a bit sparse for people who >> build and test locally. (Sorry, if they are now explained >> somewhere. Last time I checked, they were not.) >> >> TIA >> >> Chiaki >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/ba842412-5cfc-d768-a87e-bb037e41a31f%40yk.rim.or.jp >> . >> > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHnMvnKM9-603aY4zhvRFRqNkGbFR_GdJD1LS6746ThPfcZEUA%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHnMvnKM9-603aY4zhvRFRqNkGbFR_GdJD1LS6746ThPfcZEUA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAAoohzQSU2Bp5wesqVkyx2_N9ai3tKe1PButiHbaWLxwbyAULg%40mail.gmail.com.
