зеркало из https://github.com/mozilla/gecko-dev.git
e4480eabc7
For reasons I can't explain, Windows builds are failing intermittently because they are unable to locate the `hg` binary when running some SpiderMonkey test processes. These processes use mozversioncontrol.get_repository_from_env() to locate the current repository. We now store VCS info in configure. This makes it available to anything running in a build system context. This commit teaches mozversioncontrol.get_repository_from_env() to import the "buildconfig" module to locate VCS info. If the module can be imported, it is the sole source of VCS info. Otherwise, we fall back to the existing detection mechanisms. This should get rid of the intermittent failure. If it doesn't, it is still a step in the right direction because it will allow build system processes to consistently use a well-defined VCS binary. MozReview-Commit-ID: DMxXheJLRqH --HG-- extra : rebase_source : a9c599934c8c08da1fbb92a9105f5c7cba0867b3 |
||
|---|---|---|
| .. | ||
| devtools/migrate-l10n | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozversioncontrol/mozversioncontrol | ||
| README | ||
| mach_commands.py | ||
| moz.build | ||
README
This directory contains common Python code. The basic rule is that if Python code is cross-module (that's "module" in the Mozilla meaning - as in "module ownership") and is MPL-compatible, it should go here. What should not go here: * Vendored python modules (use third_party/python instead) * Python that is not MPL-compatible (see other-licenses/) * Python that has good reason to remain close to its "owning" (Mozilla) module (e.g. it is only being consumed from there). Historical information can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=775243 https://bugzilla.mozilla.org/show_bug.cgi?id=1346025