On 03/19/2013 07:33 AM, Joshua Cranmer 🐧 wrote:
On 3/18/2013 11: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.
The current master manifest approach is, in my opinion, horribly
broken: there is no way to conditionally include/exclude directories
based on criteria other than what is included in mozinfo.json--which
notably excludes things like "am I building Firefox or Thunderbird?"
File a bug. Seriously, if the lack of this metadata == "horribly
broken" then I am really glad that "horribly broken" is easy to fix.
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform