On 3/18/2013 9:27 PM, Jeff Hammel wrote: > On 03/15/2013 11:33 AM, Gregory Szorc 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: >> > <snip/> >> 3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini >> defines every xpcshell.ini that exists in the tree. >> > http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/xpcshell.ini > > > Not sure if this is meant in terms of how the submanifests or laid out > or precisely what the issue is here or what is desired; this isn't > really addressed in the rest of the email (ABICT). > > Our plan is to get more testing frameworks on manifests. See > https://bugzilla.mozilla.org/show_bug.cgi?id=852418 . This allows > fine-grained control of what is run on what platform (and whatever > other conditionals are encountered), notation for the reason tests are > disabled, and whatever other notations are desired. In addition, we > are gearing towards the ability to use and manipulate manifests via > tools and automation, such as on-the-fly generation of manifests and > information harvesting from manifests convolved with other sources. > While xpcshell currently has one "top-level" manifest (I think?), > there is no reason we couldn't have more.
Nah, I'm not against manifests. I think they make a lot of sense for things like tests. We /almost/ used them as the moz.build equivalent! I'm just opposed to centralized, monolithic lists/manifests of things when the data is actually spread out across the tree. Individual xpcshell.ini (like /services/sync/tests/unit/xpcshell.ini) are fine. What I don't like is /testing/xpcshell/xpcshell.ini. The latter simply references a bunch of the former because we don't have an easy way to aggregate all occurrences of the former in a Makefile-based build system aside from directory scanning or other funkiness. moz.build files allow us to easily capture a whole-world view. So, we can do things like dynamically generate master manifests for the current build, etc. Make sense? _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
