зеркало из https://github.com/mozilla/gecko-dev.git
071a2fe984
Before bug 938437, we had a rather large and error-prone nsStaticXULComponents.cpp used to register all modules. That was replaced with clever use of the linker, which allowed to avoid the mess that maintaining that file was. Fast forward to now, where after bug 1524687 and other work that preceded it, we have a much smaller number of remaining static xpcom components, registered via this linker hack, and don't expect to add any new ones. The list should eventually go down to zero. Within that context, it seems to be the right time to get rid of the magic, and with it the problems it causes on its own. Some of those components could probably be trivially be converted to static registration via .conf files, but I didn't want to deal with the possible need to increase the number of dummy modules in XPCOMInit.cpp. They can still be converted as a followup. Differential Revision: https://phabricator.services.mozilla.com/D26076 --HG-- extra : moz-landing-system : lando |
||
---|---|---|
.. | ||
devtools/migrate-l10n | ||
docs | ||
l10n | ||
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