On Wed, Jul 23, 2014 at 02:59:00PM +0900, Mike Hommey wrote:
> Hi,
>
> I just landed bug 1036894 and related bugs on mozilla-inbound. The short
> story is that things should now be less cumbersome.
>
> For most cases in the tree, where you want to add something to libxul,
&
On Tue, Jul 29, 2014 at 02:59:17PM +0800, Philip Chee wrote:
> On 29/07/2014 08:32, Mike Hommey wrote:
> > Hi,
> >
> > I'd like to inform you today that choosing the right variable when
> > adding a new directory to the tree just got a lot easier with the
&g
Hi,
I'd like to inform you today that choosing the right variable when
adding a new directory to the tree just got a lot easier with the
landing of bug 1043802 and bug 1043820 (on mozilla-inbound only at
the moment). Before, you had to choose from:
- DIRS
- PARALLEL_DIRS
- TEST_DIRS
- TOOL_DIR
On Fri, Jul 25, 2014 at 12:04:30AM -0400, Ehsan Akhgari wrote:
> Congratulations on getting to this stage!
>
> I would like to help dogfood this, and want to know if I can trust the data
> parity of Treeherder and TBPL, or if that is something that you would like
> testing on? IOW, should I keep
On Wed, Jul 23, 2014 at 05:10:33AM -0700, rviti...@mozilla.com wrote:
> Localstore.rdf will soon be replaced with a json store (see Bug
> 559505). I am currently planning to leave the localstore.rdf
> implementation as it is and issue a warning when a client tries to
> access to it. This is needed
Hi,
I just landed bug 1036894 and related bugs on mozilla-inbound. The short
story is that things should now be less cumbersome.
For most cases in the tree, where you want to add something to libxul,
things are mostly unchanged: just add
FINAL_LIBRARY = 'xul'
or
FINAL_LIBRARY = 'gkmedias
On Wed, Jul 02, 2014 at 01:41:54PM +0200, David Rajchenbach-Teller wrote:
> The main usecase is an editor that needs to 1/ reload resources when
> they have been modified by an outside application; 2/ see when resources
> are added or removed.
>
> In other words, watching a directory (recursively)
On Wed, Jul 02, 2014 at 02:23:51PM +0200, Dirkjan Ochtman wrote:
> On Wed, Jul 2, 2014 at 1:41 PM, David Rajchenbach-Teller
> wrote:
> > Which library do you suggest?
>
> Take a look at watchman:
>
> https://github.com/facebook/watchman
That one uses inotify as well. Might as well use glib.
Mi
On Wed, Jul 02, 2014 at 12:43:47PM +0200, Axel Hecht wrote:
> On 7/2/14 12:25 PM, Yonggang Luo wrote:
> >I am using Mozilla XUL SDK to build my own application, So I'd like
> >to know what's the format of jar.mn file
> >
>
> Took me a while to find it, but I think that
> https://ci.mozilla.org/job
On Wed, Jul 02, 2014 at 12:13:44PM +0200, David Rajchenbach-Teller wrote:
> For its recently landed WebIDE, the devtools team needs a component to
> watch changes in a directory (they are currently using a somewhat
> hackish workaround that they want to replace with something better
> supported). B
On Tue, Nov 19, 2013 at 11:02:52AM +0900, Mike Hommey wrote:
> Hi,
>
> I am going to land a long series of patches that changes how Gecko code
> linkage is defined.
>
> Currently, when you add new code (like, a new module) to Gecko, you:
> - Add a new directory
> - Edit
Hi,
If you're building on Windows, you may have heard about pymake. It has
been our make replacement for builds for a long while, until a few
months back when we introduced mozmake.
I just landed bug 1027890, which retires support for pymake in the build
system. If you were using pymake, please u
On Tue, Jun 03, 2014 at 07:32:57AM -0700, Gabor Krizsanits wrote:
> >
> > It's pretty rare that things such OS, Compiler, SDK change on our build
> > systems. We do tend to make noise about them when that happens, too. Do
> > you have specific examples to point at?
>
> Where can I follow these ch
On Tue, Jun 03, 2014 at 09:11:26AM -0700, Gregory Szorc wrote:
> On 6/3/14, 6:42 AM, Ben Hearsum wrote:
> >On 14-06-03 06:39 AM, Gabor Krizsanits wrote:
> >>>From time to time, no matter what platform I use, the build configuration
> >>>on the try server changes
> >>and from that point on it's jus
On Wed, May 21, 2014 at 10:22:44PM +0200, Emmanuel Engelhart wrote:
> On 21.05.2014 21:59, Ralph Giles wrote:
> >On 2014-05-21 9:56 AM, Emmanuel Engelhart wrote:
> >
> >>checker. But it seems the Mozilla codes uses this API for many things
> >>linked to video stuff:
> >>https://mxr.mozilla.org/mozi
On Mon, May 19, 2014 at 06:35:49PM -0700, Jonas Sicking wrote:
> On Mon, May 19, 2014 at 4:10 PM, Rik Cabanier wrote:
> > I don't see why the web platform is special here and we should trust that
> > authors can do the right thing.
>
> I'm fairly sure people have already pointed this out to you.
On Mon, May 19, 2014 at 05:07:44PM -0700, Nicholas Nethercote wrote:
> On Mon, May 19, 2014 at 3:05 PM, L. David Baron wrote:
> >> Do we still need Trace Malloc?
> >
> > Are you talking about removing it from the debug builds done on our
> > infra, or removing it from the tree?
>
> I'm aiming for
On Wed, May 14, 2014 at 05:46:23PM -0700, Tim Abraldes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Build took 41:02 with these options:
> ac_add_options --enable-chrome-format=flat
> ac_add_options --disable-optimize
> ac_add_options --enable-debug-symbols
> ac_add_options
On Mon, May 12, 2014 at 04:46:18PM -0700, Kyle Huey wrote:
> On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote:
> > On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote:
> >> We should get rid of RefPtr, just like we did the MFBT refcounting classes.
> >>
>
On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote:
> We should get rid of RefPtr, just like we did the MFBT refcounting classes.
>
> The main thing stopping a mechanical search and replace is that the
> two smart pointers have different semantics around
> already_AddRefed/TemporaryRef :(
On Mon, Apr 28, 2014 at 07:18:17AM +0300, Birunthan Mohanathas wrote:
> Bugs 900903 and 900908 introduced variadic variants of
> NS_IMPL_ISUPPORTS, NS_IMPL_QUERY_INTERFACE, NS_IMPL_CYCLE_COLLECTION,
> etc. and removed the old numbered macros. So, instead of e.g.
> NS_IMPL_ISUPPORTS2(nsFoo, nsIBar,
On Fri, Apr 25, 2014 at 12:10:24PM +0300, Henri Sivonen wrote:
> On Fri, Apr 25, 2014 at 11:26 AM, Mike Hommey wrote:
> > On Fri, Apr 25, 2014 at 10:31:44AM +0300, Henri Sivonen wrote:
> >> Using system ICU seems wrong in terms of correctness. That's the
> >> reaso
On Fri, Apr 25, 2014 at 10:31:44AM +0300, Henri Sivonen wrote:
> Using system ICU seems wrong in terms of correctness. That's the
> reason why we don't use system ICU on Mac and desktop Linux, right?
Actually the main reason is that every version of desktop linux has a
different version of ICU, wh
On Thu, Apr 24, 2014 at 07:03:09PM -0400, Ehsan Akhgari wrote:
> On 2014-04-24, 8:31 AM, Henri Sivonen wrote:
> >However, especially in the context of slimming down our own set of
> >encoding converters, it's rather demotivating to see that at least on
> >desktop, we are building ICU encoding conve
On Thu, Apr 24, 2014 at 04:15:45PM -0700, Brian Smith wrote:
> On Thu, Apr 24, 2014 at 4:03 PM, Ehsan Akhgari wrote:
>
> > * Are there obvious places that people should inspect for code that's
> >
> >> being built but not used? Some libs that got imported for WebRTC
> >> maybe?
> >>
> >
> > Noth
On Thu, Apr 24, 2014 at 10:19:11AM +0100, Neil wrote:
> Mike Hommey wrote:
>
> > mk_add_options "export MOZ_DEBUG_FLAGS=-Z7"
> >
> -Z7 is faster than -Zi?
Surprisingly, yes.
> Do VS2013 users need to turn off -FS?
Maybe, although it may j
Hi,
While working on shared compilation cache for windows, I noticed I could
get a 20% build time improvement with the following in .mozconfig:
mk_add_options "export COMPILE_PDB_FLAG="
mk_add_options "export HOST_PDB_FLAG="
mk_add_options "export MOZ_DEBUG_FLAGS=-Z7"
(the downside i
On Tue, Apr 22, 2014 at 09:25:01AM -0400, Benjamin Smedberg wrote:
> On 4/22/2014 7:31 AM, Robert O'Callahan wrote:
> >It's all over the tree, inconsistently applied. Is it relevant anymore? Can
> >we remove it entirely, or there some places where it's still relevant, and
> >if so, where ... XPCOM?
On Tue, Apr 22, 2014 at 07:25:46PM -0400, Trevor Saunders wrote:
> > No, that's just how we choose between #pragma visibility and
> > -fvisibility=hidden
>
> Well, its at least strange given the bugs mentioned in configure were
> supposedly fixed in gcc 4.1, but I wouldn't be at all suprised if
>
On Wed, Apr 23, 2014 at 10:41:06AM +1200, Robert O'Callahan wrote:
> On Wed, Apr 23, 2014 at 1:25 AM, Benjamin Smedberg
> wrote:
>
> > On 4/22/2014 7:31 AM, Robert O'Callahan wrote:
> >
> >> It's all over the tree, inconsistently applied. Is it relevant anymore?
> >> Can
> >> we remove it entirel
On Wed, Apr 16, 2014 at 09:55:02PM -0700, Vladimir Vukicevic wrote:
> On Wednesday, April 16, 2014 9:00:40 PM UTC-4, Eric Rahm wrote:
> > So who actually needs to talk to Oculus? I can try to reach out some
> > folks I used to work with who are there now and see if they're
> > interested in makin
On Mon, Apr 14, 2014 at 03:41:49PM -0700, Vladimir Vukicevic wrote:
> Hey all,
>
> I have a prototype of VR display and sensor integration with the web,
> along with an implementation for the Oculus VR. Despite there really
> being only one vendor right now, there is a lot of interest in VR.
> I'
On Tue, Apr 01, 2014 at 08:34:01PM -0400, Ehsan Akhgari wrote:
> On 2014-04-01, 7:58 PM, Mike Hommey wrote:
> >On Tue, Apr 01, 2014 at 05:32:12PM -0400, Ehsan Akhgari wrote:
> >>The subject of this post is intentionally chosen to make you want to read
> >>this. :-)
>
On Tue, Apr 01, 2014 at 05:32:12PM -0400, Ehsan Akhgari wrote:
> The subject of this post is intentionally chosen to make you want to read
> this. :-)
>
> The summary is that I think the mozilla::Atomic API which is modeled after
> std::atomic is harmful in that it makes it very non-obvious that
On Wed, Mar 26, 2014 at 11:58:48PM -0700, Doug Turner wrote:
> Want to move to github?
>
> (0) sudo apt-get install python-setuptools
> (1) sudo easy_install hg-git
> (2) add |hggit =| under [extensions] in your .hgrc file
> (3) Go to GitHub.com and create your new repo.
> (4) cd
> (5) hg bookmar
On Wed, Mar 26, 2014 at 10:40:39PM -0700, Gregory Szorc wrote:
> On 3/26/14, 10:11 PM, Mike Hommey wrote:
> >On Wed, Mar 26, 2014 at 05:40:36PM -0700, Gregory Szorc wrote:
> >>On 3/26/14, 4:53 PM, Taras Glek wrote:
> >>>*User Repos*
> >>>TLDR: I would
On Thu, Mar 27, 2014 at 02:42:13PM +0900, Mike Hommey wrote:
> On Wed, Mar 26, 2014 at 10:32:07PM -0700, L. David Baron wrote:
> > On Thursday 2014-03-27 14:11 +0900, Mike Hommey wrote:
> > > Note that while user repositories are self-service on the creation side,
> > >
On Wed, Mar 26, 2014 at 10:32:07PM -0700, L. David Baron wrote:
> On Thursday 2014-03-27 14:11 +0900, Mike Hommey wrote:
> > Note that while user repositories are self-service on the creation side,
> > there is no obvious way to self-service a user repo removal. I'm not in
On Wed, Mar 26, 2014 at 05:40:36PM -0700, Gregory Szorc wrote:
> On 3/26/14, 4:53 PM, Taras Glek wrote:
> >*User Repos*
> >TLDR: I would like to make user repos read-only by April 30th. We should
> >archive them by May 31st.
> >
> >Time spent operating user repositories could be spent reducing our
Hi,
In the coming days and weeks, there are going to be a few changes to how
we do automated build on Windows, all in the interest of faster build
times:
- Shared compilation cache is going to be deployed soon(ish). We
currently have no compilation cache at all on windows, and we're going
to h
On Wed, Mar 26, 2014 at 04:53:27PM -0700, Taras Glek wrote:
> *User Repos*
> TLDR: I would like to make user repos read-only by April 30th. We should
> archive them by May 31st.
>
> Time spent operating user repositories could be spent reducing our
> end-to-end continuous integration cycles. The
On Thu, Mar 20, 2014 at 10:26:31AM +1300, Karl Tomlinson wrote:
> Erik Rose writes:
>
> > Once we have request-time rendering of indexed content, it will
> > be a lot more straightforward to fetch and render arbitrary revs
> > out of version control the same way. We just won't have
> > analysis—on
On Fri, Mar 14, 2014 at 02:33:08PM -0700, Taras Glek wrote:
> Hi,
> I asked
> https://ask.mozilla.org/question/237/why-do-you-not-use-askmozillaorg/.
> Feedback would be appreciated.
Because it requires yet another account.
Mike
___
dev-platform mailin
On Thu, Feb 27, 2014 at 07:33:39PM +0900, Mike Hommey wrote:
> On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
> >
> > Could we compress major parts of omni.ja en block? We could for
> > example stick all JS we load at startup into a zip with zero
> > co
On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote:
>
> Could we compress major parts of omni.ja en block? We could for
> example stick all JS we load at startup into a zip with zero
> compression and then compress that into an outer zip. I think we
> already support nested containers lik
On Thu, Feb 27, 2014 at 09:30:22AM +0100, Axel Hecht wrote:
> The feature of zip we want is the index, that let's us seek to a
> position in the bundle and start unpacking, just given the filename.
>
> How hard is to actually create a datastructure for the same purpose
> for a tar.xz or so? I don'
On Thu, Feb 27, 2014 at 08:25:00AM +0900, Mike Hommey wrote:
> On Wed, Feb 26, 2014 at 08:56:37PM +0100, Andreas Gal wrote:
> >
> > This randomly reminds me that it might be time to review zip as our
> > compression format for omni.ja.
> >
> > ls -l omni.ja
On Wed, Feb 26, 2014 at 08:56:37PM +0100, Andreas Gal wrote:
>
> This randomly reminds me that it might be time to review zip as our
> compression format for omni.ja.
>
> ls -l omni.ja
>
> 7862939
>
> ls -l omni.tar.xz (tar and then xz -z)
>
> 4814416
>
> LZMA2 is available as a public domai
On Tue, Feb 25, 2014 at 07:25:56PM -0800, Nicholas Nethercote wrote:
> On Tue, Feb 25, 2014 at 2:32 PM, Mike Hommey wrote:
> >
> > I never understood why we need those jobs to be builds. Why not turn
> > --enable-valgrind on m-c builds, and run valgrind as a test job?
>
On Tue, Feb 25, 2014 at 12:53:12PM -0800, Nicholas Nethercote wrote:
> On Tue, Feb 25, 2014 at 12:48 PM, Ehsan Akhgari
> wrote:
> >>
> >> The Valgrind test job does leak checking, and it's recently caught
> >> some leaks and caused the offending patches to be backed out. However,
> >> the test co
Hi,
In an effort to make build turnaround times better, we're working on
various things, on one which is the use of a shared compilation cache
instead of a per-slave ccache. The first milestone for this project is
reached, and this shared cache is now enabled for try builds for desktop
linux[0] bu
On Fri, Jan 24, 2014 at 08:30:01AM +, Neil wrote:
> Since we're not allowed to move locale files on branches, is it
> possible for a jar.mn to refer to locale files from another part of
> the tree?
Yes. And we've done it in the past.
Mike
___
dev-pl
On Fri, Jan 17, 2014 at 01:20:50PM -0800, Kevin Brosnan wrote:
> We would need to do a 1.9.0 release.
> https://bugzilla.mozilla.org/showdependencytree.cgi?id=927213&hide_resolved=1is
> what is blocking that from happening.
I think you meant
https://bugzilla.mozilla.org/showdependencytree.cgi?id=9
On Tue, Jan 14, 2014 at 12:55:03AM -0800, ajvinc...@gmail.com wrote:
> Wow. All this just as I'm trying to get XULRunner repaired and
> stabilized for good with automated tests. I put a lot of effort into
> reviving the damn thing, and I'm close to getting it working again on
> the Mac. (More to
Hi,
Let's face it: xulrunner is hardly maintained, we barely build and test
it on automation, and the result is that it is often broken for long
periods of time.
I propose that we just stop pretending, and terminate xulrunner,
considering the following:
- Xulrunner is lagging behind Firefox: DLL
On Wed, Jan 08, 2014 at 10:23:28AM +0900, ISHIKAWA,chiaki wrote:
> (2013/09/10 19:17), ishikawa wrote:
>
> [ omissions ]
> >
> > I am getting the hang of emacs mode line.
> >
> > /* -*- Mode: javascript; tab-width: 8; indent-tabs-mode: nil;
> > c-basic-offset: 2 ; js-indent-level : 2 ; js-curl
On Tue, Jan 07, 2014 at 04:13:20PM -0800, Nicholas Nethercote wrote:
> On Tue, Jan 7, 2014 at 12:31 PM, Benjamin Smedberg
> wrote:
> >
> > I am the owner of at least the C/C++ portions of the style guide; I propose
> > to wait and see whether the C++ reformatting tools are of sufficient quality
>
On Thu, Dec 26, 2013 at 03:29:07AM +0900, ISHIKAWA,chiaki wrote:
> For quite some time (a few months at least), I noticed during the build
> of thunderbird (comm-central) that shows the memory reduction by
> elf-hack is NEGATIVE value.
>
> For example, the following is from the compilation of late
On Wed, Dec 25, 2013 at 10:00:33PM +1300, Robert O'Callahan wrote:
> The JS engine has always been a problem when trying to enforce consistent
> standards across Gecko. Part of that comes from it being viewed as an
> independent product, much more so than any other Gecko module. Another part
> of t
On Thu, Dec 19, 2013 at 11:02:08AM -0500, Ehsan Akhgari wrote:
> > How about we just use clang-format?
> > http://www.irill.org/videos/euro-llvm-2013/jasper-hires.webm
>
>
> clang-format has a basic support for the Mozilla coding style, and we can
> definitely extend it to add support for this h
On Thu, Dec 19, 2013 at 01:20:41AM -0800, Andrea Marchesini wrote:
> Hi,
>
> Writing a patch for bug 949488 I had to indent this piece of code:
>
> nsIScriptSecurityManager* ssm = nsContentUtils::GetSecurityManager();
> if (NS_WARN_IF(NS_FAILED(ssm->GetSimpleCodebasePrincipal(
>
On Tue, Dec 10, 2013 at 09:17:22AM -0600, Joshua Cranmer ? wrote:
> On 12/10/2013 3:28 AM, Chris Pearce wrote:
> >Hi All,
> >
> >Can we start using C++ STL containers like std::set, std::map,
> >std::queue in Mozilla code please? Many of the STL containers are
> >more convenient to use than our equ
Hi,
It seems a lot of people are using mozmake, which is good,
unfortunately, some are using an old version and i broke them with bug
944569. Those people need to upgrade mozmake by taking the last version
on either http://people.mozilla.org/~mhommey/mozmake.exe or
https://hg.mozilla.org/projects/
On Tue, Dec 03, 2013 at 05:54:12PM -0800, Jesse Ruderman wrote:
> In the long run, it may be more efficient to use the clang "sanitizer"
> suite instead of Valgrind. It will need two runs (ASan+LSan+UBSan and
> MSan) but the total run time should be lower.
>
> http://clang.llvm.org/docs/UsersManua
On Tue, Dec 03, 2013 at 01:30:39PM -0800, Jed Davis wrote:
> On Tue, Dec 03, 2013 at 11:47:48AM -0800, L. David Baron wrote:
> > On Tuesday 2013-12-03 10:18 -0800, Brian Smith wrote:
> > > Also, I would be very interested in seeing "size of libxul.so" for
> > > fully-optimized (including PGO, where
On Tue, Dec 03, 2013 at 10:20:20AM -0800, Chris Peterson wrote:
> On 12/3/13, 8:53 AM, Ted Mielczarek wrote:
> >On 12/2/2013 11:39 PM, Mike Hommey wrote:
> >>Current setup (16):
> >> real11m7.986s
> >> user63m48.075s
> >> sys
On Tue, Dec 03, 2013 at 12:18:46AM -0500, Boris Zbarsky wrote:
> On 12/2/13 11:39 PM, Mike Hommey wrote:
> >1. By the way, those type of bugs that show up at different number of
> >unified sources are existing type of problems waiting to arise when we
> >add source files, an
Hi,
It was already mentioned that unified builds might be causing memory
issues. Since the number of unified sources (16) was decided more or
less arbitrarily (in fact, it's just using whatever was used for
ipdl/webidl builds, which, in turn just used whatever seemed a good
tradeoff between clobbe
On Mon, Dec 02, 2013 at 06:23:00PM -0500, Ehsan Akhgari wrote:
> On 12/2/2013, 2:36 PM, Chris Peterson wrote:
> >On 11/29/13, 7:39 PM, Mike Hommey wrote:
> >>I think it's time, 9 days before the merge, to think about whether we
> >>want unified builds to ride the
On Mon, Dec 02, 2013 at 06:23:59PM -0800, skybr...@google.com wrote:
> On Wednesday, November 20, 2013 5:27:59 AM UTC-8, Benjamin Smedberg wrote:
> > On 11/20/2013 8:02 AM, Look, Yuriy wrote:
> >
> > > Hi,
> >
> > > On or around November 13 2013 Firefox of versions 25.0.1, 24.1.1 ESR
> >
> > >
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
> Hi,
>
> Unified builds have been around for about two weeks. They are nice
> because they make the build so much faster. On the other hand, we know
> they currently break crash reports on mac (bug 943695), and can br
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
> Incidentally, in those two weeks, I did two attempts at building
> without unified sources, resulting in me filing 4 bugs in different
> modules for problems caused by 6 different landings[1]. I think it is time
> to ser
Hi,
Unified builds have been around for about two weeks. They are nice
because they make the build so much faster. On the other hand, we know
they currently break crash reports on mac (bug 943695), and can break
things in subtle ways (bug 942421, bug 943839). We don't know what
problems are still
On Thu, Nov 28, 2013 at 10:26:43PM +, Neil wrote:
> Can we guarantee UTF16 literals using MOZ_UTF16("wide string here")
> these days? I'm just reviewing a patch and it's using the old-style
> NS_LITERAL_STRING("wide string here").get() pattern all over.
There's only one definition of NS_LITERA
On Thu, Nov 28, 2013 at 05:12:53PM -0500, Ehsan Akhgari wrote:
> On 11/28/2013, 4:55 PM, Mike Hoye wrote:
> >On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
> >>I'm pretty sure that gps was saying "if you're paid to work by
> >>Mozilla, get a faster machine". More generally, we're all in furious
On Wed, Nov 27, 2013 at 06:02:42AM +0100, Julien Wajsberg wrote:
> Note, for git lovers, the git remote hg helper seems to work quite well.
> see http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
>
> As an occasional gecko developer I'm giving it a try right now and see
> how it goes :)
On Mon, Nov 25, 2013 at 12:02:50PM -0500, Benjamin Smedberg wrote:
> Note that in many cases, the user hasn't actually run out of memory:
> they have plenty of physical memory and page file available. In most
> cases they also have enough available VM space! Often, however, this
> VM space is fragm
On Fri, Nov 22, 2013 at 07:24:14PM -0500, Ehsan Akhgari wrote:
> On 2013-11-22 4:25 PM, Gregory Szorc wrote:
> >On Nov 22, 2013, at 13:16, Ehsan Akhgari wrote:
> >
> >>On Fri, Nov 22, 2013 at 1:02 PM, Boris Zbarsky wrote:
> >>
> >>>On 11/22/13 11:41 AM, Ehsan Akhgari wrote:
> >>>
> Hmm to the
On Fri, Nov 22, 2013 at 08:33:31AM -0800, Armen Zambrano Gasparnian
> This would still have to deal with not getting immediate feedback for
> commits on 10.7 and 10.8 and how to deal with backouts and regression
> hunting.
Note that part is already a problem caused by coalescing.
Mike
___
On Thu, Nov 14, 2013 at 05:49:33PM -0500, Ehsan Akhgari wrote:
> I've started to work on a project in my spare time to switch us to use
> unified builds for C/C++ compilation. The way that unified builds work is
> by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build
> files.
On Thu, Nov 21, 2013 at 04:56:50PM -0500, John O'Duinn wrote:
> 6) If a developer lands a patch that works on 10.9, but it fails somehow
> on 10.7 or 10.8, it is unlikely that we would back out the fix, and we
> would instead tell users to upgrade to 10.9 anyways, for the security fixes.
It's not
On Thu, Nov 21, 2013 at 05:56:12PM -0800, Jed Davis wrote:
> On Thu, Nov 21, 2013 at 05:41:27PM -0500, Boris Zbarsky wrote:
> > On 11/21/13 3:15 PM, Gavin Sharp wrote:
> >> It would be good to explore alternatives to Bonsai.
> >> https://github.com/mozilla/mozilla-central is supposed to have full
>
On Mon, Nov 18, 2013 at 11:15:16PM -0800, Gregory Szorc wrote:
> Do builds feel like they've gotten faster in the last few weeks^hours?
> It's because they have.
>
> When I did my MacBook Pro comparison [1] with a changeset from Oct 28,
> build times on my 2013 2.6 GHz MacBook Pro were as follows:
On Tue, Nov 19, 2013 at 11:04:25AM +0800, L. David Baron wrote:
> On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote:
> > On 2013-11-17 7:50 PM, L. David Baron wrote:
> > >On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote:
> > >>On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari
> > >>wrote:
>
On Tue, Nov 19, 2013 at 03:12:23PM +1300, Robert O'Callahan wrote:
> Lovely!!!
>
> On Tue, Nov 19, 2013 at 3:02 PM, Mike Hommey wrote:
>
> > - FINAL_LIBRARY defines what library your code is going to be linked
> > into. That needs to match an existi
Hi,
I am going to land a long series of patches that changes how Gecko code
linkage is defined.
Currently, when you add new code (like, a new module) to Gecko, you:
- Add a new directory
- Edit the parent moz.build to add the directory
- Add your source files
- Add a new moz.build defining at lea
On Sat, Nov 16, 2013 at 10:34:38AM +0100, Ms2ger wrote:
> On 11/14/2013 11:49 PM, Ehsan Akhgari wrote:
> >I've started to work on a project in my spare time to switch us to use
> >unified builds for C/C++ compilation. The way that unified builds work is
> >by using the UNIFIED_SOURCES instead of t
On Thu, Nov 14, 2013 at 07:01:03PM -0500, Ehsan Akhgari wrote:
> On 2013-11-14 6:29 PM, Chris Peterson wrote:
> >On 11/14/13, 2:49 PM, Ehsan Akhgari wrote:
> >>The way that unified builds work is
> >>by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build
> >>files. With that, th
On Mon, Nov 11, 2013 at 05:23:48PM +0200, Henri Sivonen wrote:
> We are building and shipping character encoding converters that are
> dead code in Firefox but that are used in Thunderbird. Considering the
> Firefox binary size, it seems like a bad idea to ship to dead code in
> Firefox.
>
> Curre
On Wed, Nov 06, 2013 at 06:39:19PM -0800, Robert O'Callahan wrote:
> On Wed, Nov 6, 2013 at 6:21 PM, Mike Hommey wrote:
>
> > Our build system is currently building a lot of (fake) intermediate
> > static libraries, mainly for historical reasons. I am planning to fade
&g
Hi,
Our build system is currently building a lot of (fake) intermediate
static libraries, mainly for historical reasons. I am planning to fade
this away, but I also know that some subsystems rely on the possibility
to have those libraries defined for out-of-tree builds or whatever. I
think it's th
On Wed, Oct 30, 2013 at 09:56:46AM -0700, Chris Peterson wrote:
> On 10/30/13, 9:06 AM, André Reinald wrote:
> >http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security
> >
> >STACK was run against a number of systems written in C/C++ and it found
> >160 ne
On Tue, Oct 29, 2013 at 03:47:40PM -0700, Aki Sasaki wrote:
> There *may* be l10n fallout here due to a |cd config; make| and a
> followup |hg update -r REVISION| afterwards (IIRC)... let's keep an eye
> on that.
Those builds should have a step running either configure or
config.status after hg up
Hi,
As of bug 929905, which I landed earlier on mozilla-inbound, declaring
source code (as in assembler, C, C++, Objective C, Objective C++) in
moz.build changed to be (much) simpler.
Instead of using:
CPP_SOURCES,
CSRCS,
CMSRCS,
CMMSRCS,
SSRCS,
ASFILES,
now use:
SOURCES
Ins
On Tue, Oct 22, 2013 at 10:06:13AM +0100, Neil wrote:
> David Rajchenbach-Teller wrote:
>
> >Wouldn't it be interesting to also have a
> > ./mach build frontend
> >that repackages XUL and js code?
> >
> Does ./mach build chrome work? (I don't think it's parallelised
> though.) Hopefully a combinat
On Mon, Oct 21, 2013 at 10:00:13PM -0400, Hubert Figuière wrote:
> On 21/10/13 07:27 PM, Mike Hommey wrote:
> > AFAIK, running 10.7+ in 32-bit mode is something you have to do manually
> > at boot time. I guess nobody does that except for testing purpose. Also,
> > afaik 10.
On Mon, Oct 21, 2013 at 04:07:33PM -0700, Chris Peterson wrote:
> On 10/21/13 3:28 PM, Mike Hommey wrote:
> >Note OS X 10.6 runs in 32-bit mode*by default*, even on *64-bit
> >capable* hardware. That's the whole problem. There are only a few
> >Macbook models that aren&#
On Mon, Oct 21, 2013 at 08:24:15AM -0700, Nathan Froyd wrote:
> How long do we intend to continue shipping a 32-bit Firefox binary on
> OS X? As I understand it, we're doing this solely for our OS X 10.6
> users, as they are the only ones potentially running OS X on
> non-64-bit capable machines.
On Wed, Oct 16, 2013 at 08:09:23PM -0700, Nicholas Nethercote wrote:
> On Wed, Oct 16, 2013 at 6:43 AM, Mike Hommey wrote:
> >
> > I'm sure fellow developers building on Windows felt sad that they were
> > left out on the recent build improvements. Rejoice at last,
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
401 - 500 of 660 matches
Mail list logo
