>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
