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
> 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 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
Hi,
This morning I deployed a different version of _dumbwin32proc.py to all
of our Win7 (talos-r3-w7-*) and WinXP machines (talos-r3-xp-*).
This different version allows the machines to kill processes that
currently could not be killed. For instance, when we asked a job to be
interrupted. It
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
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
6 matches
Mail list logo
