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. T
On 3/15/2013 2:33 PM, Gregory Szorc wrote:
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.
Yes, I believe you are mostly correct.
With moz.build files, we n
On 13-03-15 20:06 , Benjamin Smedberg wrote:
*Also* note that we actually have two different files:
"all.js" is the defaults for the Mozilla platform, including
Tbird/Seamonkey and all XULRunner apps.
"firefox.js" is where Firefox-specific prefs and overrides typically
should live.
There is al
> From: "Kartikaya Gupta"
> On 13-03-15 20:06 , Benjamin Smedberg wrote:
> > *Also* note that we actually have two different files:
> >
> > "all.js" is the defaults for the Mozilla platform, including
> > Tbird/Seamonkey and all XULRunner apps.
> > "firefox.js" is where Firefox-specific prefs and
On 15.03.13 20:06, Benjamin Smedberg wrote:
On 3/15/2013 2:33 PM, Gregory Szorc wrote:
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.
Yes, I believe you are mo
On Sat, Mar 16, 2013 at 12:29:27AM +0100, Axel Hecht wrote:
> On 15.03.13 20:06, Benjamin Smedberg wrote:
> >On 3/15/2013 2:33 PM, Gregory Szorc wrote:
> >>
> >>
> >>I /think/ our current spaghetti configuration is a historical artifact
> >>from using Makefile.in's to define the build config combin
testing/crashtests/crashtests.list and layout/reftest/reftest.list are other
examples of a centralized location.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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:
3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini
defin
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:
>>
>
>> 3) xpcshell.ini
> 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/te
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:
3) xpcshell.ini master mani
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 a
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 so
The consensus is the master manifest solution is not of interest, are there
proposals and plans to remove:
testing/xpcshell/xpcshell.ini
testing/crashtest/crashtests.list
layout/reftest/reftests.list
This thread seems as though it is focusing on one of the 3 master manifests.
As I am working to
On 3/19/13 11:57 AM, jmaher wrote:
The consensus is the master manifest solution is not of interest, are there
proposals and plans to remove:
testing/xpcshell/xpcshell.ini
testing/crashtest/crashtests.list
layout/reftest/reftests.list
This thread seems as though it is focusing on one of the 3 m
On 3/19/2013 5:00 PM, Gregory Szorc wrote:
> If I had to weigh in, I think existing manifests like xpcshell.ini
> work good enough and might be more readable and maintainable than
> managing everything in moz.build files. But, I'm ignorant of a lot of
> things, so maybe they aren't good enough.
>
N
16 matches
Mail list logo
