2016-07-14 19:16:42 +03:00
|
|
|
# -*- Mode: python; indent-tabs-mode: nil; tab-width: 40 -*-
|
2013-02-26 00:47:23 +04:00
|
|
|
# vim: set filetype=python:
|
|
|
|
|
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
|
2017-03-09 13:33:31 +03:00
|
|
|
with Files('**'):
|
|
|
|
|
BUG_COMPONENT = ('Core', 'Preferences: Backend')
|
|
|
|
|
|
2017-04-08 17:45:10 +03:00
|
|
|
if CONFIG['ENABLE_TESTS']:
|
|
|
|
|
DIRS += ['test/gtest']
|
|
|
|
|
|
2015-02-10 19:47:27 +03:00
|
|
|
XPCSHELL_TESTS_MANIFESTS += [
|
|
|
|
|
'test/unit/xpcshell.ini',
|
|
|
|
|
'test/unit_ipc/xpcshell.ini',
|
|
|
|
|
]
|
2013-03-19 22:47:00 +04:00
|
|
|
|
2014-08-08 08:52:04 +04:00
|
|
|
XPIDL_SOURCES += [
|
|
|
|
|
'nsIPrefBranch.idl',
|
|
|
|
|
'nsIPrefLocalizedString.idl',
|
|
|
|
|
'nsIPrefService.idl',
|
|
|
|
|
'nsIRelativeFilePref.idl',
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
XPIDL_MODULE = 'pref'
|
|
|
|
|
|
|
|
|
|
EXPORTS.mozilla += [
|
Bug 1436655 - Introduce a mechanism for VarCache prefs to be defined entirely in the binary. r=glandium
Currently VarCache prefs are setup in two parts:
- The vanilla pref part, installed via a data file such as all.js, or via an
API call.
- The VarCache variable part, setup by an Add*VarCache() call.
Both parts are needed for the pref to actually operate as a proper VarCache
pref. (There are various prefs for which we do one but not the other unless a
certain condition is met.)
This patch introduces a new way of doing things. There is a new file,
modules/libpref/init/StaticPrefList.h, which defines prefs like this:
> VARCACHE_PREF(
> "layout.accessiblecaret.width",
> layout_accessiblecaret_width,
> float, 34.0
> )
This replaces both the existing parts.
The preprocessor is used to generate multiple things from this single
definition:
- A global variable (the VarCache itself).
- A getter for that global variable.
- A call to an init function that unconditionally installs the pref in the
prefs hash table at startup.
C++ files can include the new StaticPrefs.h file to access the getter.
Rust code cannot use the getter, but can access the global variable directly
via structs.rs. This is similar to how things currently work for Rust code.
Non-VarCache prefs can also be declared in StaticPrefList.h, using PREF instead
of the VARCACHE_PREF.
The new approach has the following advantages.
+ It eliminates the duplication (in all.js and the Add*VarCache() call) of the
pref name and default value, preventing potential mismatches. (This is a real
problem in practice!)
+ There is now a single initialization point for these VarCache prefs.
+ This avoids need to find a place to insert the Add*VarCache() calls, which
are currently spread all over the place.
+ It also eliminates the common pattern whereby these calls are wrapped in a
execute-once block protected by a static boolean (see bug 1346224).
+ It's no longer possible to have a VarCache pref for which only one of the
pieces has been setup.
+ It encapsulates the VarCache global variable, so there is no need to declare
it separately.
+ VarCache reads are done via a getter (e.g. StaticPrefs::foo_bar_baz())
instead of a raw global variable read.
+ This makes it clearer that you're reading a pref value, and easier to
search for uses.
+ This prevents accidental writes to the global variable.
+ This prevents accidental mistyping of the pref name.
+ This provides a single chokepoint in the code for such accesses, which make
adding checking and instrumentation feasible.
+ It subsumes MediaPrefs, and will allow that class to be removed. (gfxPrefs is
a harder lift, unfortunately.)
+ Once all VarCache prefs are migrated to the new approach, the VarCache
mechanism will be better encapsulated, with fewer details publicly visible.
+ (Future work) This will allow the pref names to be stored statically, saving
memory in every process.
The main downside of the new approach is that all of these prefs are in a
single header that is included in quite a few places, so any changes to this
header will cause a fair amount of recompilation.
Another minor downside is that all VarCache prefs are defined and visible from
start-up. For test-only prefs like network.predictor.doing-tests, having them
show in about:config isn't particularly useful.
The patch also moves three network VarCache prefs to the new mechanism as a
basic demonstration. (And note the inconsistencies in the multiple initial
values that were provided for
network.auth.subresource-img-cross-origin-http-auth-allow!) There will be
numerous follow-up bugs to convert the remaining VarCache prefs.
MozReview-Commit-ID: 9ABNpOR16uW
* * *
[mq]: fixup
MozReview-Commit-ID: 6ToT9dQjIAq
2018-03-26 01:39:40 +03:00
|
|
|
'init/StaticPrefList.h',
|
2018-08-21 00:28:00 +03:00
|
|
|
'nsRelativeFilePref.h',
|
2014-08-08 08:52:04 +04:00
|
|
|
'Preferences.h',
|
Bug 1436655 - Introduce a mechanism for VarCache prefs to be defined entirely in the binary. r=glandium
Currently VarCache prefs are setup in two parts:
- The vanilla pref part, installed via a data file such as all.js, or via an
API call.
- The VarCache variable part, setup by an Add*VarCache() call.
Both parts are needed for the pref to actually operate as a proper VarCache
pref. (There are various prefs for which we do one but not the other unless a
certain condition is met.)
This patch introduces a new way of doing things. There is a new file,
modules/libpref/init/StaticPrefList.h, which defines prefs like this:
> VARCACHE_PREF(
> "layout.accessiblecaret.width",
> layout_accessiblecaret_width,
> float, 34.0
> )
This replaces both the existing parts.
The preprocessor is used to generate multiple things from this single
definition:
- A global variable (the VarCache itself).
- A getter for that global variable.
- A call to an init function that unconditionally installs the pref in the
prefs hash table at startup.
C++ files can include the new StaticPrefs.h file to access the getter.
Rust code cannot use the getter, but can access the global variable directly
via structs.rs. This is similar to how things currently work for Rust code.
Non-VarCache prefs can also be declared in StaticPrefList.h, using PREF instead
of the VARCACHE_PREF.
The new approach has the following advantages.
+ It eliminates the duplication (in all.js and the Add*VarCache() call) of the
pref name and default value, preventing potential mismatches. (This is a real
problem in practice!)
+ There is now a single initialization point for these VarCache prefs.
+ This avoids need to find a place to insert the Add*VarCache() calls, which
are currently spread all over the place.
+ It also eliminates the common pattern whereby these calls are wrapped in a
execute-once block protected by a static boolean (see bug 1346224).
+ It's no longer possible to have a VarCache pref for which only one of the
pieces has been setup.
+ It encapsulates the VarCache global variable, so there is no need to declare
it separately.
+ VarCache reads are done via a getter (e.g. StaticPrefs::foo_bar_baz())
instead of a raw global variable read.
+ This makes it clearer that you're reading a pref value, and easier to
search for uses.
+ This prevents accidental writes to the global variable.
+ This prevents accidental mistyping of the pref name.
+ This provides a single chokepoint in the code for such accesses, which make
adding checking and instrumentation feasible.
+ It subsumes MediaPrefs, and will allow that class to be removed. (gfxPrefs is
a harder lift, unfortunately.)
+ Once all VarCache prefs are migrated to the new approach, the VarCache
mechanism will be better encapsulated, with fewer details publicly visible.
+ (Future work) This will allow the pref names to be stored statically, saving
memory in every process.
The main downside of the new approach is that all of these prefs are in a
single header that is included in quite a few places, so any changes to this
header will cause a fair amount of recompilation.
Another minor downside is that all VarCache prefs are defined and visible from
start-up. For test-only prefs like network.predictor.doing-tests, having them
show in about:config isn't particularly useful.
The patch also moves three network VarCache prefs to the new mechanism as a
basic demonstration. (And note the inconsistencies in the multiple initial
values that were provided for
network.auth.subresource-img-cross-origin-http-auth-allow!) There will be
numerous follow-up bugs to convert the remaining VarCache prefs.
MozReview-Commit-ID: 9ABNpOR16uW
* * *
[mq]: fixup
MozReview-Commit-ID: 6ToT9dQjIAq
2018-03-26 01:39:40 +03:00
|
|
|
'StaticPrefs.h',
|
2014-08-08 08:52:04 +04:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
UNIFIED_SOURCES += [
|
|
|
|
|
'Preferences.cpp',
|
2018-07-02 04:28:31 +03:00
|
|
|
'SharedPrefMap.cpp',
|
2014-08-08 08:52:04 +04:00
|
|
|
]
|
|
|
|
|
|
2019-01-30 03:03:41 +03:00
|
|
|
XPCOM_MANIFESTS += [
|
|
|
|
|
'components.conf',
|
|
|
|
|
]
|
|
|
|
|
|
2014-08-08 08:52:04 +04:00
|
|
|
include('/ipc/chromium/chromium-config.mozbuild')
|
|
|
|
|
|
|
|
|
|
FINAL_LIBRARY = 'xul'
|
|
|
|
|
|
|
|
|
|
DEFINES['OS_ARCH'] = CONFIG['OS_ARCH']
|
|
|
|
|
DEFINES['MOZ_WIDGET_TOOLKIT'] = CONFIG['MOZ_WIDGET_TOOLKIT']
|
Bug 1342450 - Extract a MOZ_ENABLE_WEBRENDER from MOZ_BUILD_WEBRENDER so that we build but disable by default. r=rhunt,froydnj,ted
This adds back a MOZ_ENABLE_WEBRENDER define, which only controls whether or
not WebRender is enabled at runtime. The default behaviour is changed so that:
- if the user specifies --disable-webrender in the mozconfig, WebRender is
neither built nor enabled
- if the user specifies --enable-webrender in the mozconfig, WebRender is
built and enabled
- if the user specifies --enable-webrender=build in the mozconfig, WebRender is
built but not enabled, except on Android where it is neither built nor enabled
- if the user doesn't specify any of the above, the default behaviour is:
- on nightly/local builds, the same as --enable-webrender=build
- on other channels (e.g. aurora), the same as --disable-webrender
The net effect is that local/Nightly-automation builds will have WebRender
built-in but not enabled where possible (i.e. not Android). However the user
can override this behaviour via mozconfig options to either not build WebRender
at all, or to enable it in addition to building it.
MozReview-Commit-ID: IM7DdSHkIB
2017-03-23 00:38:09 +03:00
|
|
|
if CONFIG['MOZ_ENABLE_WEBRENDER']:
|
|
|
|
|
DEFINES['MOZ_ENABLE_WEBRENDER'] = True
|
2015-09-23 07:39:03 +03:00
|
|
|
|
2019-03-28 02:33:00 +03:00
|
|
|
FINAL_TARGET_PP_FILES += [
|
2015-10-28 08:39:27 +03:00
|
|
|
'greprefs.js',
|
|
|
|
|
]
|
