On 03/18/2013 09:45 PM, Gregory Szorc wrote:
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?
Maybe? ;) I'd have to see a bug etc for more of an opinion.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
