зеркало из https://github.com/mozilla/gecko-dev.git
8afaba2056
Maybe back when .cargo/config.in was added, the directory indicated for vendored crates needed to be absolute. That is at least not the case with the current supported versions of rust. The current setup has a few caveats: - .cargo/config.in has shown to become stale (it currently contains multiple unused entries) - non-gecko build tasks have to generate a .cargo/config on their own if they want to use vendored crates - in turn, non-gecko build tasks that don't, may unknowingly get their dependencies from crates.io (see the recent attempt at moving geckodriver builds to a separate task). By checking in a .cargo/config file, we can alleviate the last two, but that comes at the price of `cargo update` not wanting to act when .cargo/config exists, because of the source replacement configuration. But rust vendor gently generates a suitable configuration on its own, so we can use that to generate a .cargo/config automatically. Which addresses the first caveat of the current setup. That leaves us with `cargo update` not working out of the box, but that just requires people running it to manually remove .cargo/config first. Which is arguably what rust wants you to do in the first place. It's kind of incidental that we started with a .cargo/config.in rather than .cargo/config. Now, while a simple .cargo/config works, that's not enough for the case where the objdir doesn't live inside the source directory. In that case cargo looks for the configuration from the objdir, and fails to find it. So we still need a .cargo/config.in, which we generate with a little trick. Differential Revision: https://phabricator.services.mozilla.com/D43012 --HG-- rename : .cargo/config.in => .cargo/config extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| config | ||
| config.in | ||