Re: Faster gecko builds with IceCC on Mac and Linux

[Randell Jesup]

>On 1/16/18 2:59 PM, smaug wrote:

>Would it be possible that when I do an hg pull of mozilla-central or
>mozilla-inbound, I can also choose to download the object files from the
>most recent ancestor that had an automation build? (It could be a separate
>command, or ./mach pull.) They would go into a local ccache (or probably
>sccache?) directory. The files would need to be atomically updated with
>respect to my own builds, so I could race my build against the
>download. And preferably the download would go roughly in the reverse order
>as my own build, so they would meet in the middle at some point, after
>which only the modified files would need to be compiled. It might require
>splitting debug info out of the object files for this to be practical,
>where the debug info could be downloaded asynchronously in the background
>after the main build is complete.

Stolen from a document on Workflow Efficiencies I worked on:

Some type of aggressive pull-and-rebuild in the background may help
by providing a ‘hot’ objdir that can be switched to in place of the
normal “hg pull -u; ./mach build” sequence.

Users would need to deal with reloading editor buffers after
switching, but that’s normal after a pull.  If the path changes it
might require more magic; Emacs could deal with that easily with an
elisp macro; not sure about other editors people use.  Keeping paths
to source the same after a pull is a win, though.

Opportunistic rebuilds as you edit source might help, but the win is
much smaller and would be more work.  Still worth looking at,
especially if you happen to touch something central.

We'd need to be careful how it interacts with things like hg pull,
witching branches, etc (defer starting builds slightly until source
has been unchanged for N seconds?)

I talked a fair bit about this with ted and others.  The main trick here
would be in dealing with cache directories, and with sccache we could
make it support a form of hierarchy for caches (local and remote), so
you could leverage either local rebuilds-in-background (triggered by
automatic pulls on repo updates), or remote build resources (such as
from the m-c build machines).

Note that *any* remote-cache utilization depends on a fixed (or at least
identical-and-checked) configuration *and* compiler and system
includes.  The easiest way to acheive this might be to leverage a local
VM instance of taskcluster, since system includes vary
machine-to-machine, even for the same OS version.  (Perhaps this is less
of an issue on Mac or Windows...).

This requirement greatly complicates things (and requires building a
"standard" config, which many do not).  Leveraging local background
builds would be much easier in many ways, though also less of a win.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: nsIDOMWindowUtils.sendKeyEvent() and nsIFrameLoader.sendCrossProcessKeyEvent()

[Masayuki Nakano]

Hi,

I'd like to remove legacy API to dispatch keyboard events.

One is nsIDOMWindowUtils.sendKeyEvent(), this has already replaced 
completely with nsITextInputProcessor [*1] since 2015 [*2].  It's really 
easy to rewrite legacy API users with new API because our EventUtils.js 
for mochitest has a good wrapper for using new API [*3].


The other is nsIFrameLoader.sendCrossProcessKeyEvent().  This was 
implemented for old Fennec [*4] and looks like that nobody uses this API 
now.  This shares same implementation with 
nsIDOMWindowUtils.sendKeyEvent() but dispatches keyboard events only in 
the remote process associated with the frame loader. Unfortunately, we 
don't have alternative API for this.  However, if the remote process has 
focus, keyboard events synthesized with nsITextInputProcessor are sent 
to the remote process.  So, I guess that we don't need this API anymore.


I'm working on this at bug 1134542:
https://bugzilla.mozilla.org/show_bug.cgi?id=1134542

Thunderbird still uses nsIDOMWindowUtils.sendKeyEvent().  Therefore, 
I'll wait to land the removing patch until those bugs [*5][*6] are 
fixed.  However, if they won't be fixed by the next weekend, I'll drop 
these legacy API soon anyway.


*1 
https://searchfox.org/mozilla-central/source/dom/interfaces/base/nsITextInputProcessor.idl

*2 https://bugzilla.mozilla.org/show_bug.cgi?id=917322
*3 
https://searchfox.org/mozilla-central/rev/97cb0aa64ae51adcabff76fb3b5eb18368f5f8ab/testing/mochitest/tests/SimpleTest/EventUtils.js#835-905

*4 https://bugzilla.mozilla.org/show_bug.cgi?id=553149
*5 https://bugzilla.mozilla.org/show_bug.cgi?id=1433648
*6 https://bugzilla.mozilla.org/show_bug.cgi?id=1434317

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform