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?"
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
