mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-24 21:31:04 +00:00
0ac52aa9d7
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode but also other modules, like `dom/Animation`, as an example, in the non unified environment. This approach is desirable since we already have most of the modules transitioned to the non unified system but there are still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested locally using the build system. If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False` To also enable this we need to have a flag from `mozconfig`, like: ``` ac_add_options --disable-unified-build ``` Differential Revision: https://phabricator.services.mozilla.com/D122328 |
||
---|---|---|
.. | ||
devtools/migrate-l10n | ||
docs | ||
gdbpp/gdbpp | ||
l10n | ||
lldbutils | ||
mach | ||
mozboot | ||
mozbuild | ||
mozlint | ||
mozperftest | ||
mozrelease | ||
mozterm | ||
mozversioncontrol | ||
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