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
