On Mon, Jul 30, 2012 at 09:23:43AM +0100, Mark Banner wrote:
On 19/07/2012 21:38, Alex Keybl wrote:
Thanks to everyone who joined this discussion. We've now moved
forward with disabling OS X 10.5 support for FF17 in [1]. Per
discussion here, we will strive to leave code in place through the 17
On Thu, Aug 09, 2012 at 12:26:33PM -0400, Justin Lebar wrote:
This will however
bitrot most of your patches, so I have put together a script here
https://bugzilla.mozilla.org/attachment.cgi?id=650572 which helps you
unbitrot them. This script handles mq patches, and needs to be run in the
On Fri, Aug 10, 2012 at 09:24:57AM +0100, Neil wrote:
Ehsan Akhgari wrote:
PRIntn - int32_t
PRUintn - uint32_t
http://mxr.mozilla.org/comm-central/source/mozilla/nsprpub/pr/include/prtypes.h#385
typedef int PRIntn;
typedef unsigned int PRUintn;
What is it you're trying to say?
On Fri, Aug 10, 2012 at 10:03:04AM +0100, Neil wrote:
Mike Hommey wrote:
On Fri, Aug 10, 2012 at 09:24:57AM +0100, Neil wrote:
Ehsan Akhgari wrote:
PRIntn - int32_t
PRUintn - uint32_t
http://mxr.mozilla.org/comm-central/source/mozilla/nsprpub/pr/include/prtypes.h#385
typedef int
On Thu, Aug 16, 2012 at 09:18:11AM -0400, Ben Hearsum wrote:
On 08/16/12 02:10 AM, Mike Hommey wrote:
But maybe we can work around this. At least for rm -rf, instead of
rm -rf'ing before the build, we could move the objdir away so that a
fresh new one is created. The older one could
On Wed, Aug 22, 2012 at 03:56:33PM +1200, Blair McBride wrote:
On 22/08/2012 11:36 a.m., Gregory Szorc wrote:
I think Lua is perfect for this (it was invented to be a configuration
language after all). But, I'm not sure it satisfies #1 nor #8.
+1 for Lua - it seems perfect for this. For #1,
On Thu, Aug 23, 2012 at 01:07:34AM +1200, Blair McBride wrote:
On 22/08/2012 5:58 p.m., Mike Hommey wrote:
+1 for Lua - it seems perfect for this. For #1, I find it far easier
to read (and write) than Gyp, when it comes to things like
conditionals. For #8, we could just ship the entire runtime
On Wed, Aug 22, 2012 at 04:12:30PM -0700, Justin Lebar wrote:
bholley and I have a script for doing this in git. With thanks to
glandium for telling us how to do it:
0. Fetch the prtypes change, and merge it into your local master branch.
1. Let your git checkout be directory |src|.
2.
On Wed, Aug 22, 2012 at 01:38:22PM -0700, Gregory Szorc wrote:
On 8/22/12 1:00 PM, Ben Hearsum wrote:
On 08/22/12 12:43 PM, Jeff Hammel wrote:
If we do go with python, it would be nice to keep the configuration
files as much configuration as possible. The reason I question having
any full
On Thu, Aug 23, 2012 at 08:43:31AM -0400, Ben Hearsum wrote:
Yeah, I think I agree. My experience in RelEng has biased me strongly
towards not allowing even temporary hacks like that, because it's rare
that we ever remove them, and end up with a pile of very difficult to
maintain hacks
On Fri, Sep 14, 2012 at 08:41:19AM -0400, Ehsan Akhgari wrote:
OK, time for some good news. John Schoenick helped me yesterday on
IRC to understand what has caused this issue and how to fix it. I
tried that and it indeed fixed the problem. I'm currently in the
process of converting the rest
On Wed, Sep 19, 2012 at 05:47:15PM -0400, Ehsan Akhgari wrote:
On 12-09-19 5:08 PM, Steve Fink wrote:
On 09/19/2012 06:33 AM, Ehsan Akhgari wrote:
On 12-09-19 1:01 AM, L. David Baron wrote:
On Wednesday 2012-09-19 00:04 -0400, Ehsan Akhgari wrote:
A while ago (I think more than a couple of
On Fri, Sep 28, 2012 at 06:45:24AM -0400, Benoit Jacob wrote:
2012/9/28 Aryeh Gregor a...@aryeh.name:
On Thu, Sep 27, 2012 at 6:08 PM, Gregory Szorc g...@mozilla.com wrote:
I actually held out on you with the initial landing of mach: there is more
advanced tree building code in the pipes,
On Fri, Sep 28, 2012 at 05:34:09PM +0200, Honza Bambas wrote:
On 9/28/2012 12:58 PM, Mike Hommey wrote:
On Fri, Sep 28, 2012 at 06:45:24AM -0400, Benoit Jacob wrote:
2012/9/28 Aryeh Gregor a...@aryeh.name:
On Thu, Sep 27, 2012 at 6:08 PM, Gregory Szorc g...@mozilla.com wrote:
I actually held
On Wed, Oct 03, 2012 at 02:54:19PM +0200, Axel Hecht wrote:
On 03.10.12 14:33, Mike Hommey wrote:
On Wed, Oct 03, 2012 at 02:01:02PM +0200, Axel Hecht wrote:
I've looked a bit deeper into the code, and there's unused
functionality that I'd like to rip out of JarMaker.py in favor
On Wed, Oct 03, 2012 at 03:52:38PM +0200, Axel Hecht wrote:
On 03.10.12 15:41, Mike Hommey wrote:
On Wed, Oct 03, 2012 at 02:54:19PM +0200, Axel Hecht wrote:
On 03.10.12 14:33, Mike Hommey wrote:
On Wed, Oct 03, 2012 at 02:01:02PM +0200, Axel Hecht wrote:
I've looked a bit deeper
On Mon, Oct 08, 2012 at 12:05:58PM -0700, Gregory Szorc wrote:
We now have a tool in mozilla-central that has a much better UX for
running tests (mach). It's not perfect yet, but it's getting there
(please write patches!).
The build peers (or at least a few of us) really don't like the make
On Mon, Oct 08, 2012 at 11:10:37PM -0400, Zack Weinberg wrote:
On 2012-10-08 3:05 PM, Gregory Szorc wrote:
We now have a tool in mozilla-central that has a much better UX for
running tests (mach). It's not perfect yet, but it's getting there
(please write patches!).
The build peers (or at
On Wed, Oct 10, 2012 at 05:57:53PM -0400, Justin Lebar wrote:
By turning off Linux PGO testing, you really mean stop making and
distributing Linux PGO builds, right?
The main reason I'd want Linux PGO is for mobile. On desktop Linux,
most users (I expect) don't run our builds, so it's not a
On Thu, Oct 11, 2012 at 02:26:33PM -0400, Rafael Ávila de Espíndola wrote:
On 10/11/2012 02:33 AM, Mike Hommey wrote:
On Wed, Oct 10, 2012 at 05:57:53PM -0400, Justin Lebar wrote:
By turning off Linux PGO testing, you really mean stop making and
distributing Linux PGO builds, right
On Thu, Oct 11, 2012 at 06:38:57PM -0400, Ehsan Akhgari wrote:
On 2012-10-11 6:36 PM, Mike Hommey wrote:
On Thu, Oct 11, 2012 at 06:14:51PM -0400, Ted Mielczarek wrote:
On Thu, Oct 11, 2012 at 4:20 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
What I really don't want us to do
On Mon, Oct 29, 2012 at 06:11:04PM -0700, Gregory Szorc wrote:
On 10/29/12 5:52 PM, Robert O'Callahan wrote:
On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
#pragma once does have one drawback (other than being non-standard)
and that is if you have the
On Mon, Nov 12, 2012 at 03:47:32PM -0800, Alex Keybl wrote:
Bug 799295 [1], the driver for this thread, is still an open issue for
FF18 (shipping in 6 weeks). The JS team's recommendation remains to
disable PGO on Linux. According to Taras, the major benefits of PGO on
Linux are for a
On Tue, Nov 13, 2012 at 05:22:22PM -0800, Ehsan Akhgari wrote:
On 2012-11-13 5:03 PM, Justin Dolske wrote:
On 11/13/12 4:34 PM, Ehsan Akhgari wrote:
But the point here is that unless we know for sure that we're dealing
with a compiler bug, disabling Linux PGO builds may just wallpaper over
On Mon, Dec 03, 2012 at 09:11:58PM +0100, Mike Hommey wrote:
On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1, 2] in
SpiderMonkey, and as an aid
On Tue, Dec 04, 2012 at 07:51:21AM -0500, Justin Wood (Callek) wrote:
Rafael Ávila de Espíndola wrote:
Actually, ICU has several options for how its data is packaged. One option
is libraries (which are not sharable between architectures, AFAIK), but
another possibility is to use data
On Mon, Jan 14, 2013 at 11:09:07AM -0500, Benoit Jacob wrote:
2013/1/14 Mike Hommey m...@glandium.org
On Mon, Jan 14, 2013 at 11:43:44AM +1300, Robert O'Callahan wrote:
I need a big read-only buffer full of zeroes. On Linux I could mmap
/dev/zero read-only, and something similar
On Mon, Jan 14, 2013 at 11:28:19AM -0500, Benoit Jacob wrote:
2013/1/14 Mike Hommey m...@glandium.org
On Mon, Jan 14, 2013 at 11:09:07AM -0500, Benoit Jacob wrote:
2013/1/14 Mike Hommey m...@glandium.org
On Mon, Jan 14, 2013 at 11:43:44AM +1300, Robert O'Callahan wrote:
I need
On Tue, Jan 15, 2013 at 03:19:42PM +, Neil wrote:
Mike Hommey wrote:
On Tue, Jan 15, 2013 at 11:28:28AM +, Neil wrote:
Mike Hommey wrote:
It just maps anonymous memory (for big enough sizes)
Note that big enough is pretty large, I think 4MB in jemalloc's case.
It's 1MB
On Tue, Jan 22, 2013 at 10:52:39AM +1300, Robert O'Callahan wrote:
Exactly what control do we have over what gets PGOed? In particular:
1) Are we able to exclude particular object files or libraries from PGO
when we link libxul, reducing PGO memory usage for the final link? I think
you said
On Mon, Jan 21, 2013 at 10:56:28PM +0100, Mike Hommey wrote:
On Tue, Jan 22, 2013 at 10:52:39AM +1300, Robert O'Callahan wrote:
Exactly what control do we have over what gets PGOed? In particular:
1) Are we able to exclude particular object files or libraries from PGO
when we link libxul
Hi,
I landed bug 780561, which replaced a bunch of awful Makefile goo around
a perl script (and a few other things) with a quite well unittested python
codebase.
While it doesn't affect everyday development, and doesn't change the
Firefox, Firefox for Android and B2G tinderbox builds much, there
On Wed, Jan 23, 2013 at 03:38:05PM -0500, Joe Drew wrote:
On 2013-01-22 5:27 PM, Mike Hommey wrote:
FWIW, IIRC my experiments last time we had this problem, LTCG alone
accounts for less than a third of the performance boost we get from
PGO on Talos.
Did you happen to measure how big
On Mon, Jan 28, 2013 at 12:32:58PM -0500, Ehsan Akhgari wrote:
On 2013-01-28 3:38 AM, Brian Smith wrote:
Ehsan Akhgari wrote:
I have started an effort to gather some information on what options
we have with regard to using PGO on Windows in the longer term[.]
If you have ideas
which are
On Wed, Jan 30, 2013 at 11:49:01PM -0500, Ehsan Akhgari wrote:
The decrease is unfortunately not linear, as it seems like the big
memory eater is LTCG, and unfortunately we cannot opt out of that if
we want to do any PGO.
Well, LTCG is only going to compile objects that have been compiled
with
On Thu, Jan 31, 2013 at 01:07:39PM -0500, Ted Mielczarek wrote:
After consideration, I think we ought to just bite the bullet and
disable PGO. We have no other way to fix this issue. All other work we
can do simply pushes it down the road. As our recent history has shown,
we simply don't have
Hi,
We're planning to land the final part of bug 755724 on monday,
targetting tuesday's nightly as the first nightly with the separation
done. This is the final step before being able to land Metro support on
mozilla-central.
This will only apply to Desktop Firefox, although other applications
On Thu, Feb 21, 2013 at 10:21:09AM -0500, Mike Habicher wrote:
On 13-02-21 08:41 AM, Justin Lebar wrote:
Can guidance be
provided as to where to get such things for commonly-run versions of Linux?
It's also easy to install hg using pip or easy_install. You can get
either of these tools using
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 combined with the
On Wed, Mar 27, 2013 at 01:42:31PM -0700, Bas Schouten wrote:
A more detailed description of the proposal and the workflows involved
can be found here
(https://wiki.mozilla.org/Platform/GFX/Moz2DSubrepository) for those
interested in the details. Since we believe if we go through with this
it
On Mon, Apr 01, 2013 at 09:04:00AM -0400, Ryan VanderMeulen wrote:
For 4 months now, we've been dealing with intermittent segfaults in
gcc during compilation, most often in IonBuilder.cpp. We've been
tracking these failures in bug 820796. Given that this is pointing
to a compiler bug, it seems
On Mon, Apr 01, 2013 at 12:21:41PM -0400, Ryan VanderMeulen wrote:
On 4/1/2013 12:06 PM, Mike Hommey wrote:
gcc 4.7.2 was installed on builders last week. Unfortunately, it comes
with its own set of problems. See bugs 854085, 854103 and 854105. The
worst part (which is unfiled at the moment
On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote:
FYI: Upgrading binutils to 2.23.2 did not help.
(Well, at least I got a better memory usage report when
memory was exhausted. ld printed out that it fails to allocate this many
bytes after having allocated the total amount. They are
On Wed, Apr 10, 2013 at 08:23:37PM -0700, Gregory Szorc wrote:
Mercurial and Git both support the ability to attach arbitrary key-value
string data to commits. There is an abundance of awesomeness that could
be realized if we started storing [machine readable] information inside
our commits
On Thu, Apr 11, 2013 at 12:57:46PM -0400, Justin Lebar wrote:
It bothers me that we're cluttering up our commit messages with
ephemeral data unrelated to the actual change. DONTBUILD and CLOSED
TREE are the worst offenders.
What if we asked people to put DONTBUILD / CLOSED TREE in a new
Hi,
For almost three months now, we've had graphs following the amount of
memory used by the linker on Windows builders during PGO builds. The
result can be seen here:
http://graphs.mozilla.org/graph.html#tests=[[205,63,8]]sel=nonedisplayrange=90datatype=running
The first thing to notice in
On Sat, Apr 13, 2013 at 10:28:47AM +0200, Mike Hommey wrote:
I think we need to start thinking how to make PGO opt-in instead of
opt-out, while keeping performance where it is now.
In fact, I'm wondering if at this point it wouldn't just make sense to
start the other way around
On Tue, Apr 16, 2013 at 05:39:30AM -0500, Jim Mathies wrote:
We also still have bug 845840 - File a support request with ms on
our pgo problems. As soon as we sort out the account stuff we can
file something.
I doubt we can get a satisfactory response from MS before things blow
out (if at all)
On Sun, Apr 21, 2013 at 07:51:18PM -0400, Justin Lebar wrote:
I think we should consider using much less JS in the parts of Gecko that are
used in B2G. I'd like us to consider writing new modules in C++ where
possible, and I'd like us to consider rewriting existing modules in C++.
I'm only
On Mon, Apr 22, 2013 at 10:53:40AM -0400, Justin Lebar wrote:
How about pre-compiling JS in JITed form?
While significant, it seems that memory used for script source isn't
the biggest offender.
Full details are in the about:memory reports,
On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
Also, they cannot be represented in git
I doubt this is true. The bridging tools may well not support it, but
there's nothing structural about multiple-head repository that would
prevent them to be mirrored in git.
Mike
On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote:
On 2013-05-02 9:40 AM, Mike Hommey wrote:
On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
Also, they cannot be represented in git
I doubt this is true. The bridging tools may well not support it, but
there's
On Fri, May 03, 2013 at 02:59:21AM -0400, Ehsan Akhgari wrote:
On 2013-05-03 2:52 AM, Mike Hommey wrote:
On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote:
On 2013-05-02 9:40 AM, Mike Hommey wrote:
On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
Also, they cannot
On Fri, May 03, 2013 at 02:55:09AM -0400, Ehsan Akhgari wrote:
Does it also build browser/app on OSX after every build? Since that is
pretty much required all the time and often missed.
Why is that always required? I never build browser/app and have not
noticed any problems at least for
On Mon, May 06, 2013 at 07:27:08AM -0400, Benoit Jacob wrote:
2013/5/6 Robert O'Callahan rob...@ocallahan.org
We expose HTML and SVG content to Web applications by structuring that
content as a tree and then exposing it using standard DOM APIs. These APIs
let you examine, manipulate,
Hi,
With the increasing number of reports of local builds for Linux and
Android hitting the 32-bits address space limits when linking, and with
the fact that gcc 4.7 on try does hit that limit on PGO builds, it has
become necessary to switch the 32-bits Linux and Android builds to
64-bits
On Wed, May 15, 2013 at 11:42:33AM +0200, Mike Hommey wrote:
Hi,
With the increasing number of reports of local builds for Linux and
Android hitting the 32-bits address space limits when linking, and with
the fact that gcc 4.7 on try does hit that limit on PGO builds, it has
become
On Thu, May 16, 2013 at 01:30:14PM -0400, Subrata Mazumdar wrote:
I have now tested with with Firefox-22 as beta and ot still does not
work. Please see the attached message for the description of the
problem.
I think that the problem is related to mismatch between the shared
libraries in
On Fri, May 24, 2013 at 08:40:29AM -0700, Michael Hoye wrote:
- Original Message -
From: Benjamin Smedberg benja...@smedbergs.us To: Scott
Johnson sjohn...@mozilla.com Cc: dev-platform@lists.mozilla.org,
Michael Hoye mh...@mozilla.com
* Automated tools: mhoye has identified
On Tue, May 28, 2013 at 09:29:46PM -0700, Lawrence Mandel wrote:
I would also prefer an agenda that is set before the meeting and need
to discuss this with those who will be contributing to the agenda. I
think a day in advance might be pushing it given when I see most
Mozilla meeting agendas
On Thu, May 30, 2013 at 05:56:43PM -0700, Johnny Stenback wrote:
[TL;DR, I think we need to embrace git in addition to hg for
Firefox/Gecko hacking, what do you think?]
Hello everyone,
The question of whether Mozilla engineering should embrace git usage for
Firefox/Gecko development has
On Tue, Jun 25, 2013 at 11:52:03AM -0700, Gregory Szorc wrote:
tl;dr You may experience a change in behavior in build performance
In bug 884587, we just changed how file purging occurs during builds.
Due to historical reasons (notably bad build dependencies and to
prevent old files from
On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
We've dropped support for versions of MSVC prior to 2010, and we're
requiring at least GCC 4.4. According to [0] that means we should be able
to use *auto*. Anybody know any reasons why we can't start using it?
We can't require any
On Sun, Jul 14, 2013 at 10:50:55PM -0700, Justin Lebar wrote:
We can't require any c++11 feature until we drop support for gcc
4.4. [...] there are problems in the gcc 4.4 system headers that
make using c++11 mode impossible (except on b2g/android).
Is there any reason to support gcc 4.4
On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
We've dropped support for versions of MSVC prior to 2010, and we're
requiring at least GCC 4.4. According to [0] that means we should be
able to use *auto*. Anybody know any reasons why we can't start using
it?
Filed bug 894242.
On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote:
On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
We've dropped support for versions of MSVC prior to 2010, and we're
requiring at least GCC 4.4. According to [0] that means we should
be able to use *auto*. Anybody know
Hi,
As it seems there is a trend towards using in-tree mozconfigs for local
developer builds, I think a reminder is in order:
In-tree mozconfigs are for buildbot consumption.
For Firefox desktop builds, a mozconfig should be unnecessary for most
people, except if their compiler is not
On Thu, Jul 18, 2013 at 10:51:10AM +0900, Mike Hommey wrote:
Hi,
As it seems there is a trend towards using in-tree mozconfigs for
local developer builds, I think a reminder is in order:
In-tree mozconfigs are for buildbot consumption.
For Firefox desktop builds, a mozconfig
On Wed, Jul 17, 2013 at 10:29:01PM -0700, Dave Townsend wrote:
On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey m...@glandium.org wrote:
Hi,
As it seems there is a trend towards using in-tree mozconfigs for
local developer builds, I think a reminder is in order:
In-tree
On Thu, Jul 18, 2013 at 11:34:53AM -0400, Ehsan Akhgari wrote:
On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
From that table, using the gcc and msvc versions, that gives:
gcc msvcclang auto 4.4 10.0*
Yes
Yes,
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
On Fri, Jul 19, 2013 at 3:34 AM, Ehsan Akhgari
ehsan.akhg...@gmail.comwrote:
On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
r-value references 4.3@
On Fri, Jul 19, 2013 at 03:45:13PM -0400, Ehsan Akhgari wrote:
On 2013-07-19 3:26 PM, Ehsan Akhgari wrote:
On 2013-07-18 10:46 PM, Mike Hommey wrote:
On Thu, Jul 18, 2013 at 08:54:02PM -0500, Joshua Cranmer ? wrote:
On 7/18/2013 7:15 PM, Robert O'Callahan wrote:
On Fri, Jul 19, 2013 at 3:34
On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote:
On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.org
wrote:
On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey m...@glandium.org
wrote:
Note that STL is another story. We're not using libstdc++ that
comes
On Wed, Jul 31, 2013 at 10:25:15AM +0200, Brian Smith wrote:
We should be more aggressive in requiring newer compiler versions
whenever practical, and we should choose to support as few
compiler/library combinations as we can get away with. That way we can
use as many C++11/14 features (not
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote:
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org wrote:
I strongly oppose to any requirement that would make ESR+2 (ESR31)
not build on the current Debian stable (gcc 4.7) and make ESR+1
(ESR24) not build
On Wed, Jul 31, 2013 at 10:28:38AM -0700, Justin Lebar wrote:
Wouldn't switching branches in the same repo clone touch many files
and trigger unfortunately clobber builds? Even with ccache and
separate per-branch objdirs, this seems like a problem.
Yes.
Nothing about this proposal
On Thu, Aug 01, 2013 at 04:13:23PM -0700, Gregory Szorc wrote:
We have a number of references to OS/2 throughout the build system
and source tree. According to Kyle Huey OS/2 has likely broken since
we removed --disable-ipc (bug 638755) in March 2011.
There have been OS/2-related changes
CCing the last two persons who submitted patches for OS/2
On Thu, Aug 01, 2013 at 04:13:23PM -0700, Gregory Szorc wrote:
We have a number of references to OS/2 throughout the build system
and source tree. According to Kyle Huey OS/2 has likely broken since
we removed --disable-ipc (bug 638755)
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
Debian doesn't keep Iceweasel up to date in oldstable anyway.
Actually, I'm providing backports for oldstable. 24 is as far as I'm
ready to go to support oldstable until its actual EOL next year. Which
is why i want ESR24 to remain
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote:
On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey m...@glandium.org wrote:
On Thu, Aug 01, 2013 at 04:25:25PM -0700, Matt Brubeck wrote:
Debian doesn't keep Iceweasel up to date in oldstable anyway.
Actually, I'm providing
On Fri, Aug 02, 2013 at 06:47:08PM -0400, Ehsan Akhgari wrote:
On 2013-08-02 5:21 PM, Brian Smith wrote:
3. How should we handle bridge support for standardized features not yet
universally-implemented?
Generally, I would much rather we implement std::whatever ourselves than
implement
On Fri, Aug 02, 2013 at 02:44:57PM -0700, Justin Lebar wrote:
I agree that iostream-based logging would be safer. If we had it I
wouldn't have had to work on this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=855335
I can't access that bug, but maybe you mean
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote:
On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
This adds too much risk of security patches failing to backport from
mozilla-central to ESR 24. Remember that one of the design goals of ESR
is to
On Sat, Aug 03, 2013 at 01:36:15PM +1000, Nicholas Nethercote wrote:
(...)
Even worse, link times are through the roof. I was thrilled when, two
years ago, I switched from ld to gold and linking time plummeted. The
first link after rebooting was always slow, but I could link libxul
back then
On Sat, Aug 03, 2013 at 04:47:29PM +0900, Mike Hommey wrote:
On Sat, Aug 03, 2013 at 01:36:15PM +1000, Nicholas Nethercote wrote:
(...)
Even worse, link times are through the roof. I was thrilled when, two
years ago, I switched from ld to gold and linking time plummeted. The
first link
On Thu, Aug 08, 2013 at 08:15:29PM -0700, Brian Smith wrote:
On Thu, Aug 8, 2013 at 3:57 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-08-08 11:34 AM, Brian Smith wrote:
My position is that we should fix STLPort's implementation
for GCC 4.4 ARM Linux (maybe just backport a
Hi,
As the subject indicates, this message is about two completely unrelated
small things that landed recently. I didn't feel like writing two
different messages.
Steve Find wrote a perl script[1] a while ago[2] to help recursively update
uuids in interfaces and their decendents.
1.
On Tue, Aug 13, 2013 at 04:39:57PM -0700, Nicholas Nethercote wrote:
On Tue, Aug 13, 2013 at 3:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
Reducing our #include dependency will help speed up the compilation for
C/C++ files, and will also help us build fewer files after each
Hi everyone,
There's been a lot of traction recently about our builds getting slower
and what we could do about it, and what not.
Starting with bug 904979, I would like to change the way we're thinking
about default flags and options. And I am therefore opening a discussion
about it.
The main
On Fri, Aug 16, 2013 at 05:43:22PM +0800, Andreas Gal wrote:
First of all, thanks for raising this. Its definitely a problem that
needs fixing.
I am not convinced by your approach though. In a few months from now
disabling WebRTC is like calling for the DOM or JS or CSS to be
disabled in
On Mon, Aug 19, 2013 at 05:15:13PM -0700, Nicholas Nethercote wrote:
Hi,
Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has
indicated that jsapi.h is probably responsible for more recompilation
than any other file in the Mozilla tree -- it gets included in *lots*
of files,
On Mon, Aug 26, 2013 at 06:23:09PM -0400, Ehsan Akhgari wrote:
On 2013-08-26 6:16 PM, Mike Shal wrote:
On 08/25/2013 12:05 PM, Ehsan Akhgari wrote:
Note that the code itself (and not just its size) being compiled can also
change the compilation time, as the compiler needs to perform things
On Fri, Aug 30, 2013 at 03:16:27PM +0100, Ed Morley wrote:
On 30 August 2013 15:14:54, Ed Morley wrote:
For platform:
https://hg.mozilla.org/releases/mozilla-release/file/tip/config/milestone.txt
For Firefox (and yeah currently the same as platform):
On Wed, Sep 04, 2013 at 12:31:02AM -0700, Gregory Szorc wrote:
Assuming it sticks, bug 896797 just landed in inbound and changes
how EXPORTS/headers are installed. This may impact your developer
workflow if you modify EXPORTS in a moz.build file to add/remove
headers.
Previously, headers
On Wed, Sep 04, 2013 at 10:28:21AM +0100, L. David Baron wrote:
On Wednesday 2013-09-04 00:31 -0700, Gregory Szorc wrote:
Assuming it sticks, bug 896797 just landed in inbound and changes
how EXPORTS/headers are installed. This may impact your developer
workflow if you modify EXPORTS in a
On Wed, Sep 04, 2013 at 11:35:19AM -0700, Gregory Szorc wrote:
On 9/4/13 3:04 AM, Mike Hommey wrote:
On Wed, Sep 04, 2013 at 10:57:26AM +0100, L. David Baron wrote:
The way the tier build works is that we effectively make export in all
directories of a same tier before make libs. In practice
Hi,
Assuming it sticks, bug 912293 made it unnecessary to start Makefile.in
files with the usual boilerplate:
DEPTH = @DEPTH@
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
relativesrcdir = @relativesrcdir@
include $(DEPTH)/config/autoconf.mk
All of the above can now
On Thu, Sep 05, 2013 at 12:24:11PM +0200, Axel Hecht wrote:
Hi,
out of curiousity, I recall that relativesrcdir was actually the
trigger to switch on and off some l10n functionality in jar
packaging.
Is that now on everywhere?
I didn't find any l10n jar.mn without a relativesrcdir in the
On Thu, Sep 05, 2013 at 04:08:50PM +0200, Axel Hecht wrote:
On 9/5/13 1:17 PM, Mike Hommey wrote:
On Thu, Sep 05, 2013 at 12:24:11PM +0200, Axel Hecht wrote:
Hi,
out of curiousity, I recall that relativesrcdir was actually the
trigger to switch on and off some l10n functionality in jar
On Sun, Sep 08, 2013 at 05:29:03PM -0700, Nicholas Nethercote wrote:
0:19.91 /usr/bin/ld.gold.real: warning: skipping incompatible
//usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so while searching for
gtk-x11-2.0
0:19.91 /usr/bin/ld.gold.real: error: cannot find -lgtk-x11-2.0
(The full list is
1 - 100 of 565 matches
Mail list logo
