> 1) Preferences and all.js. We currently define most of the default > preferences in /modules/libpref/src/init/all.js. There are things in there > related to the browser, Necko, gfx, dom, etc. Prety much the kitchen sink.
> 2) Telemetry histograms. They are all defined in > /toolkit/components/telemetry/Histograms.json. Same deal as all.js: bits from > multiple modules all exist here. If the proposal is that each module could have its own prefs and histograms files, I am not convinced this would be an improvement over the current situation. At the very least, we should consider the downsides to splitting these files up. The putative advantages to splitting these files up are > * including increased utility of |hg log| > * easier code comprehension (since everything is self-contained). > * faster builds (from splitting up Histograms.json, bug 831104). I don't think splitting up the files would result in a big improvement in any of these areas. To address each in turn: > * including increased utility of |hg log| Splitting up the files would also decrease the utility of hg/git log. Right now it's easy to say "show me all pref changes in all.js." But if we split all.js up into many separate files, I'd have to do |git log foo/bar/prefs.js foo/baz/prefs.js ...| Module boundaries are always blurry, so "show me all image pref changes" wouldn't necessarily be as simple as |git log image/prefs.js|. For example, the pref for image locking is "content.image.allow_locking". I think this is an image pref, but obviously whoever wrote it thought it was a content pref. > * easier code comprehension (since everything is self-contained). I don't think this is a big advantage. Modules are so large, the only way to navigate around one is by searching. Does the fact that I have to use my editor's find command to navigate all.js really stand in the way of comprehension? Again splitting the files also makes code comprehension more difficult in some circumstances. Currently, if I want to find out a pref's value in b2g, I have search through two files. Under the proposed scheme, I'd have to search through N files. This is a net loss in my ability to comprehend the code. > * faster builds (from splitting up Histograms.json, bug 831104). We could accomplish these build speedups by putting the split-up probe-definition files all in one directory (instead of spreading them around the tree). That would be fine with me, if the build speedups here are something that we really want. In practice, we have lots of headers that are included all over the tree. Some of them (e.g. nsContentUtils.h) are modified quite often. I'd rather focus on making "rebuild-the-world" builds faster (e.g. with PCH) than try to fix each of these cases piecemeal. In addition to not having large benefits, splitting up prefs and telemetry would have considerable costs. The two big ones which come to mind are: * Increased difficulty figuring out "what's the default value of pref X on product Y?" because given a pref name it's not clear where it lives in the tree. (Establishing a simple function mapping pref names to tree locations would require mass-modifying a lot of pref names, which would break users who have those prefs set to custom values, so I don't think we can do that.) * What happens when two files define the same pref? In order to be sane, we'd have to make that a build error. But then because some modules can be disabled conditionally, some pref files will be disabled conditionally. This introduces a whole new combinatorial way to break the build with weird configurations. -Justin On Sat, Mar 16, 2013 at 3:33 AM, Gregory Szorc <g...@mozilla.com> wrote: > Our build config has a number of areas where metadata is centrally defined > and a module or component's "configuration" is fragmented in the source > tree. Here are some examples: > > 1) Preferences and all.js. We currently define most of the default > preferences in /modules/libpref/src/init/all.js. There are things in there > related to the browser, Necko, gfx, dom, etc. Prety much the kitchen sink. > > 2) Telemetry histograms. They are all defined in > /toolkit/components/telemetry/Histograms.json. Same deal as all.js: bits > from multiple modules all exist here. > > 3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini defines > every xpcshell.ini that exists in the tree. > > I think all of these (and more) are sub-optimal because it creates a strong > and possibly unwanted coupling between modules while fragmenting a > module/component's code. In my ideal world, I'd like to see as much of the > code as possible for a module/component be self-contained and loosely > coupled from the rest of the tree. There are a number of reasons for this, > including increased utility of |hg log| and easier code comprehension (since > everything is self-contained). The latter likely results in less tree cruft > over time. In case of Telemetry histograms, decoupling can even make the > tree build faster (bug 831104). > > I /think/ our current spaghetti configuration is a historical artifact from > using Makefile.in's to define the build config combined with the complexity > required to do things right. > > With moz.build files, we now have a mechanism to facilitate decentralized > declaration of configuration and metadata. For example, instead of defining > all preferences in /modules/libpref/src/init/all.js, we could have multiple > prefs files each declared through multiple moz.build files. moz.build tree > traversal would discover all relevant prefs files and the build code in > /modules/libpref would simply concatenate that set of files together. No > action outside of your module would be required! > > Anyway, the main point of this post is first to inform: we can now handle > decentralized metadata properly in the build config. Please consider > avoiding coupling and "module contamination." Second, does anyone have any > objections to an initiative to decouple existing monolithic build config > components? Specifically, I'd like to start by nuking the in-tree all.js and > moving preference declarations to alongside the code they control. (all.js > would be completely automatically generated.) Does anyone really care for a > monolithic all.js? The only concern I can think of is search discovery. But, > we could easily name all prefs files *.prefs.js to facilitate searching. > Thoughts? > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
