Hi,
If you are using git-cinnabar on Mac or Windows, *and* have used `git
cinnabar download` *and* are using a version of the git-cinnabar release
branch that is less than 4 days old as of writing, please upgrade to
version 0.4.0rc2 and read the release notes:
https://github.com/glandium/git-cinna
On Wed, Dec 21, 2016 at 12:41:37AM -0600, J. Ryan Stinnett wrote:
> On Wed, Dec 21, 2016 at 12:23 AM, Jim Blandy
> wrote:
> > I had a .mozconfig file that included the line:
> >
> > . "$topsrcdir/build/mozconfig.common"
>
> My understanding is that we're generally not supposed to include the
> in
On Fri, Dec 23, 2016 at 12:07:28PM +0200, smaug wrote:
> On 12/20/2016 03:46 PM, Jan de Mooij wrote:
> > Hi all,
> >
> > A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked
> > to inform dev-platform about this, so here's a quick overview.
> > mozilla::Result is based on Rust's Re
On Sun, Dec 25, 2016 at 05:35:40PM -0800, zbranie...@mozilla.com wrote:
> While preparing for the transition to the new localization framework,
> I noticed[0] that we use a large number of loosely overlapping
> build-time variables to indicate different combinations of widgets,
> platforms and GUIs
On Thu, Jan 12, 2017 at 02:42:52AM -0500, Boris Zbarsky wrote:
> On 1/12/17 2:30 AM, gsquel...@mozilla.com wrote:
> > This way all users of SomeClass only need to include SomeClass.h, not
> > SomeType.h, when they want to call SomeClass::foo.
>
> They don't need to have SomeType.h included merely
On Thu, Feb 28, 2013 at 02:52:23AM -0800, saur m wrote:
> I also tried copying dll files from my build system to other test
> system but still no successful results. Still getting same error. Any
> ideas???
In
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prer
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
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
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 se
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 (wh
On Mon, Apr 01, 2013 at 10:54:35AM -0700, Chris Peterson wrote:
> On 4/1/13 9:06 AM, 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
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 ar
On Mon, Apr 08, 2013 at 08:09:08PM -0400, Justin Lebar wrote:
> > AIUI, on Windows the smallest block you can ask for with VirtualAlloc
> > is 4 KiB. However, no more than one VirtualAlloc block can exist per
> > 64 KiB chunk. So if you ask for 4 KiB you'll end up wasting the
> > remaining 60 KiB
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
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=none&displayrange=90&datatype=running
The first thing to notice in h
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 aro
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
On Wed, Apr 17, 2013 at 07:36:40PM +0200, Robert Kaiser wrote:
> Gregory Szorc schrieb:
> >Theoretically, yes. And I do empathize with the desire to have them
> >alphabetical.
>
> As Ms2ger notes, we probably cannot have that for *DIRS, though. I
> know at least one case where this is crucial, and
On Wed, Apr 17, 2013 at 12:36:05PM -0700, Gregory Szorc wrote:
> On 4/17/13 11:52 AM, Ralph Giles wrote:
> >On 13-04-17 10:20 AM, Gregory Szorc wrote:
> >
> >>I agree the behavior is not expected if you're coming from a traditional
> >>configure + make background. However, I believe automatic clobb
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 o
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,
>
> http://people.mozilla.org/~jlebar/dow
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 tool
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, E
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 f
On Fri, May 03, 2013 at 05:54:17PM -0400, Justin Lebar wrote:
> See https://bugzilla.mozilla.org/show_bug.cgi?id=809430#c39 for details.
>
> As roc points out, this has broken |mach build |. Stay tuned in
> the bug if you're interested in whether we resolve this by backing out
> the change or fix
On Sun, May 05, 2013 at 04:04:44PM -0400, Ehsan Akhgari wrote:
> clang-format is a source code formatting tool developed by Google which can
> do automatic whitespace cleanup, vertical alignment and line breaking
> changes to C++ code. See this video [1] for a recent presentation about
> the tool
On Mon, May 06, 2013 at 07:27:08AM -0400, Benoit Jacob wrote:
> 2013/5/6 Robert O'Callahan
>
> > 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, parse and seriali
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 environm
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,
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
> librari
On Thu, May 16, 2013 at 03:15:48PM -0400, Ted Mielczarek wrote:
> Longer-term this should buy us more time for a real solution, as new
> directories won't automatically contribute to the problem. We heard from
> Microsoft that they are working on a 64-to-32-bit cross-toolchain, which
> is the only
On Thu, May 16, 2013 at 10:50:18AM +0200, Mike Hommey wrote:
> > Following this, we're going to switch all Linux builds to gcc 4.7, later
> > this week.
>
> Chances are this is not going to happen this week. Something in the last
> 569 changesets before 15ba59a74221
On Fri, May 24, 2013 at 08:40:29AM -0700, Michael Hoye wrote:
> - Original Message -
>
> > From: "Benjamin Smedberg" To: "Scott
> > Johnson" Cc: dev-platform@lists.mozilla.org,
> > "Michael Hoye"
>
> > * Automated tools: mhoye has identified lack of automated review as
> > one of our b
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 agenda
On Thu, May 30, 2013 at 10:11:25PM -0400, Ehsan Akhgari wrote:
> Thanks for starting this conversation, jst.
>
> As an advocate of git in general, I actually think option #1
> (maintaining both git and hg as first class citizens) makes a lot
> more sense for us. The benefits of git in my opinion
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
On Tue, Jun 25, 2013 at 10:01:15AM +0300, Henri Sivonen wrote:
> On Tue, Jun 25, 2013 at 6:08 AM, Brian Smith wrote:
> > At the same time, I doubt such a policy is necessary or helpful for the
> > modules
> > that I am owner/peer of (PSM/Necko), at least at this time. In fact, though
> > I
> > h
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 fr
On Mon, Jul 01, 2013 at 05:43:01PM +0100, Anne van Kesteren wrote:
> I'd like to discuss the implications of replacing/morphing Gecko's URL
> parser with/into something that conforms to
> http://url.spec.whatwg.org/
>
> The goal is to get URL parsing to the level of quality of our CSS and
> HTML p
On Tue, Jul 02, 2013 at 07:09:04AM -0400, Benjamin Smedberg wrote:
> On 7/2/2013 6:55 AM, Anne van Kesteren wrote:
> >On Tue, Jul 2, 2013 at 12:51 AM, Mike Hommey wrote:
> >>Note that some "custom" schemes may be relying on empty host names. In
> >>Gecko,
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
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
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 at
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 F
On Wed, Jul 17, 2013 at 10:29:01PM -0700, Dave Townsend wrote:
> On Wed, Jul 17, 2013 at 6:51 PM, 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:
>
On Wed, Jul 17, 2013 at 05:09:22PM +0900, Mike Hommey wrote:
> 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
> > >
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
>
>
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
> >wrote:
> >
> >>On 2013-07-18 5:48 AM, mscl...@googlemail.com wrote:
> >>
> >> r-value references 4.3@10.0! Yes
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'C
On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote:
> On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith
> wrote:
>
> > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey
> > wrote:
> >
> > > Note that STL is another story. We're not using libstdc++ that
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 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
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 thi
On Wed, Jul 31, 2013 at 12:41:12PM -0500, Joshua Cranmer ? wrote:
> Thoughts/comments/corrections/questions/concerns/flames/insightful
> discussion?
My feeling is that, while these are interesting questions, they are one
step ahead. I think we should step back and start by defining what we
want to
On Thu, Aug 01, 2013 at 10:08:32AM -0700, Tim Abraldes wrote:
> > > Sadly, mercurial doesn't support having multiple working directories
> > > from a single clone, which would be useful to avoid wasting so much
> > > disk space on .hg.
> >
> > I'm 85% sure that Mercurial, on filesystems that suppo
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 lan
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 63875
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 co
On Fri, Aug 02, 2013 at 08:27:02AM -0400, Ehsan Akhgari wrote:
> On Thu, Aug 1, 2013 at 7:46 PM, Mike Hommey 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.
> >
>
On Fri, Aug 02, 2013 at 04:32:08PM -0700, Gregory Szorc wrote:
> On 8/2/13 3:38 PM, Ehsan Akhgari wrote:
> >Hmm. I'm not sure if the number of source files is directly correlated
> >to build times, but yeah there's clearly a trend here!
>
> I concede a lines of code count would be a better indica
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
>
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
> https://bug
On Sat, Aug 03, 2013 at 02:14:10AM +0200, Brian Smith wrote:
> On Sat, Aug 3, 2013 at 12:51 AM, Ehsan Akhgari wrote:
>
> > 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 minimize the a
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 t
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 ti
On Thu, Aug 08, 2013 at 08:15:29PM -0700, Brian Smith wrote:
> On Thu, Aug 8, 2013 at 3:57 PM, Ehsan Akhgari wrote:
>
> > 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 fixed version)
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. http://peo
On Tue, Aug 13, 2013 at 04:39:57PM -0700, Nicholas Nethercote wrote:
> On Tue, Aug 13, 2013 at 3:34 PM, Ehsan Akhgari
> 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 change. We
> > have a
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 th
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
> disabl
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 fi
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 th
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):
> >https://hg.mozilla.org/release
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, heade
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
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, this means
> > xpcom had access to every header in platform already, and any tier built
> > before
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
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 be
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
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
> &
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 lis
On Sun, Sep 08, 2013 at 08:52:23PM -0400, Benoit Jacob wrote:
> We have many other headers including ; it would be interesting
> to compare the percentage of our cpp files that recursively include
> before and after that patch; I suppose that just a single patch
> like that is not enough to move t
On Mon, Sep 09, 2013 at 10:12:35AM +0900, Mike Hommey wrote:
> On Sun, Sep 08, 2013 at 08:52:23PM -0400, Benoit Jacob wrote:
> > We have many other headers including ; it would be interesting
> > to compare the percentage of our cpp files that recursively include
> > before
On Wed, Sep 11, 2013 at 06:49:58AM +0100, Jonathan Kew wrote:
> However, several concerns regarding LZMA (lack of formal
> specification combined with complexity of the code, making careful
> security review and maintenance difficult; relatively slow
> decompression)
Another problem with LZMA is t
On Wed, Sep 11, 2013 at 09:12:53AM -0400, Jeff Muizelaar wrote:
>
> On 2013-09-11, at 5:55 AM, Mike Hommey wrote:
>
> > On Wed, Sep 11, 2013 at 06:49:58AM +0100, Jonathan Kew wrote:
> >> However, several concerns regarding LZMA (lack of formal
> >> specificatio
On Wed, Sep 11, 2013 at 04:39:37PM -0700, jmaher wrote:
> quite possibly we don't need all those jobs running on tegras. I
> don't know of a bug in the product that has broken on either the tegra
> or panda platform but not the other.
Off the top of my head:
- I have broken one but not the other
On Thu, Sep 12, 2013 at 07:19:54AM -0400, Benoit Jacob wrote:
> 2013/9/12 Avi Hal
>
> > On Sunday, September 8, 2013 6:22:01 AM UTC+3, Benoit Jacob wrote:
> > > Hi,
> > >
> > >
> > >
> > > It seems that we have some much-included header files including
> >
> > >
> > > just to get std::min and st
Hi everyone,
I'm sure the answer to the question asked in the subject of this thread
opener ranges somewhere between "yes" and "OH YEAH BRING IT TO ME ALREADY".
Our build system, you might know, is full of traps, and hard not to
break in subtle ways. So it is with extreme care that I landed bug
9
On Fri, Sep 20, 2013 at 09:06:41AM -0400, Benjamin Smedberg wrote:
> Currently, extensions are able to use the JSAPI via its exported
> symbols. This pretty much invariably leads to stability or security
> issues with extensions that actually do this:
>
> * the JSAPI is complicated, and even withi
On Fri, Sep 20, 2013 at 06:58:20PM +1000, Nicholas Nethercote wrote:
> On Fri, Sep 20, 2013 at 3:58 PM, Mike Hommey wrote:
> >
> > Add the following to your .mozconfig:
> >
> > export MOZ_PSEUDO_DERECURSE=1
> >
> > That's it.
>
> I just
On Fri, Sep 20, 2013 at 02:58:26PM +0900, Mike Hommey wrote:
> When it is demonstrated to be robust, it will be made the default for
> non-releng builds (not for windows until bug 918652 is fixed somehow
> in-tree).
I just landed bug 920919 on inbound. Assuming it sticks, t
Hi,
If you've read the "You want faster builds, don't you" thread, you may
know that some build improvements have recently landed.
I just landed the most important part of it all, and we should now be in
a much better place, but, as I'm very cautious, and as this is
incremental improvements to an
On Wed, Oct 02, 2013 at 11:42:45AM -0400, Ehsan Akhgari wrote:
> I just did a no-op ./mach build binaries on my debug build on a Mac,
> and it took about 28 seconds.
>
> $ time ./mach build binaries
> 0:01.96 /usr/bin/make -j8 -s binaries
> 0:12.19 From ./dist/public: Kept 0 existing; Added/upda
On Wed, Oct 09, 2013 at 08:18:16PM -0700, Nicholas Nethercote wrote:
> At the summit a few of us were talking about ways to promote Rust.
> One idea was to rewrite a smallish, well-separated component of
> Firefox in Rust, to (a) gain the benefits (parallelism, safety) of
> Rust, and (b) promote Ru
On Fri, Oct 11, 2013 at 10:23:20PM -0400, Kyle Huey wrote:
> Are you sure? I thought we killed pluggable decoders a while back.
Indeed. https://bugzilla.mozilla.org/show_bug.cgi?id=513681#c7
Mike
___
dev-platform mailing list
dev-platform@lists.mozilla
Hi,
Episode 1 was the "You want faster builds, don't you" thread.
Episode 2 was the "Faster builds, now" thread.
Here comes episode 3.
I'm sure fellow developers building on Windows felt sad that they were
left out on the recent build improvements. Rejoice at last, as we are
now bringing those to
201 - 300 of 660 matches
Mail list logo
