зеркало из https://github.com/mozilla/gecko-dev.git
b2837054ff
This adds just enough host shared library support for this one use case, but also takes shortcuts, because fully supporting host shared library is a deep rabbit hole I'm not ready to take just to fix --enable-lto --enable-clang-plugin on mac builds. One downside is that one my machine the plugin now takes > 80s to build, instead of 15s before, thanks to the lack of unified sources. --HG-- extra : rebase_source : bf52a72a01d4e3eb77cf52b646b19734b9273075 |
||
|---|---|---|
| .. | ||
| devtools/migrate-l10n | ||
| docs | ||
| l10n/fluent_migrations | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozrelease | ||
| mozterm | ||
| mozversioncontrol | ||
| safety | ||
| 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