mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
b7addff074
As content in moz.build files has grown, it has become clear that storing everything in one global namespace (the "context") per moz.build file will not scale. This approach (which is carried over from Makefile.in patterns) limits our ability to do things like declare multiple instances of things (like libraries) per file. A few months ago, templates were introduced to moz.build files. These started the process of introducing separate contexts / containers in each moz.build file. But it stopped short of actually emitting multiple contexts per container. Instead, results were merged with the main context. This patch takes sub-contexts to the next level. Introduced is the "SubContext" class. It is a Context derived from another context. SubContexts are special in that they are context managers. With the context manager is entered, the SubContext becomes the main context associated with the executing sandbox, temporarily masking the existence of the main context. This means that UPPERCASE variable accesses and writes will be handled by the active SubContext. This allows SubContext instances to define different sets of variables. When a SubContext is spawned, it is attached to the sandbox executing it. The moz.build reader will now emit not only the main context, but also every SubContext that was derived from it. To aid with the creation and declaration of sub-contexts, we introduce the SUBCONTEXTS variable. This variable holds a list of classes that define sub-contexts. Sub-contexts behave a lot like templates. Their class names becomes the symbol name in the sandbox. |
||
---|---|---|
.. | ||
bitstring | ||
blessings | ||
configobj | ||
eme | ||
jsmin | ||
lldbutils | ||
mach | ||
mock-1.0.0 | ||
mozboot | ||
mozbuild | ||
mozversioncontrol/mozversioncontrol | ||
psutil | ||
pyasn1 | ||
pystache | ||
pyyaml | ||
redo | ||
virtualenv | ||
which | ||
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: * 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 ## pyyaml | pystache Used in taskcluster related mach commands to update download from github and remove .git and tests. Then run tests in taskcluster/tests/