mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
Gecko engine for Wine
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. |
||
---|---|---|
accessible | ||
addon-sdk | ||
b2g | ||
browser | ||
build | ||
caps | ||
chrome | ||
config | ||
content | ||
db/sqlite3 | ||
docshell | ||
dom | ||
editor | ||
embedding | ||
extensions | ||
gfx | ||
hal | ||
image | ||
intl | ||
ipc | ||
js | ||
layout | ||
media | ||
memory | ||
mfbt | ||
mobile | ||
modules | ||
mozglue | ||
netwerk | ||
nsprpub | ||
other-licenses | ||
parser | ||
probes | ||
profile | ||
python | ||
rdf | ||
security | ||
services | ||
startupcache | ||
storage | ||
testing | ||
toolkit | ||
tools | ||
uriloader | ||
view | ||
webapprt | ||
widget | ||
xpcom | ||
xpfe | ||
xulrunner | ||
.clang-format | ||
.clang-format-ignore | ||
.gdbinit | ||
.gitignore | ||
.hgignore | ||
.hgtags | ||
.lldbinit | ||
aclocal.m4 | ||
Android.mk | ||
AUTHORS | ||
client.mk | ||
client.py | ||
CLOBBER | ||
configure.in | ||
GNUmakefile | ||
LEGAL | ||
LICENSE | ||
mach | ||
Makefile.in | ||
moz.build | ||
mozilla-config.h.in | ||
README.txt |
An explanation of the Mozilla Source Code Directory Structure and links to project pages with documentation can be found at: https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure For information on how to build Mozilla from the source code, see: http://developer.mozilla.org/en/docs/Build_Documentation To have your bug fix / feature added to Mozilla, you should create a patch and submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at: http://developer.mozilla.org/en/docs/Creating_a_patch http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree If you have a question about developing Mozilla, and can't find the solution on http://developer.mozilla.org, you can try asking your question in a mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups are accessible on Google Groups, or news.mozilla.org with a NNTP reader.] You can download nightly development builds from the Mozilla FTP server. Keep in mind that nightly builds, which are used by Mozilla developers for testing, may be buggy. Firefox nightlies, for example, can be found at: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/ - or - http://nightly.mozilla.org/