forked from mirrors/gecko-dev
6707a5c1ab
The auto-bootstrap code gracefully handles the lack of information as to what toolchains are available in spidermonkey standalone trees, but the fallback code path for when toolchains are not to be unpacked doesn't handle the situation. By making the toolchains themselves define whether they are to be unpacked, we can remove the fallback code path and use auto-bootstrap in all cases. This makes `mach artifact toolchain --from-build` stop requiring a manual `--no-unpack`, but `--from-task` still needs it because it can't infer that information, as it doesn't have the task graph. Original Revision: https://phabricator.services.mozilla.com/D231342 Differential Revision: https://phabricator.services.mozilla.com/D231846 |
||
|---|---|---|
| .. | ||
| docs | ||
| gdbpp/gdbpp | ||
| l10n | ||
| lldbutils | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozperftest | ||
| mozrelease | ||
| mozterm | ||
| mozversioncontrol | ||
| sites | ||
| 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