On 3/25/14, 6:21 PM, Mike Hommey wrote:
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 have a cache shared by all slaves.
- Switching builds to mozmake.
The latter is the one that makes the biggest change to developers: we
will effectively stop using pymake on automation. Usually, such things
follow with quick degradation, so if you're still using pymake for your
local builds, please consider switching to mozmake soon.
If you are using "mach build", this happens automatically if mozmake is
installed on your machine. Mozmake comes in MozillaBuild 1.9.0pre posted
a few months ago by RyanVM, and there shortly will be a MozillaBuild
1.9 release with a refreshed mozmake build. Upgrading to MozillaBuild
1.9 when it's released will get you mozmake builds automatically, if
you're using "mach build". If you're still calling pymake directly,
please run mozmake instead.
Let me also give another incentive for the switch, besides decreasing
the chances of build breakage, by telling you why we're switching builds
to mozmake and why we didn't do it earlier.
When we initially released mozmake, we set up a disposable branch using
it and it turned out not to create massive wins on automation. There was
still a local benefit from the use of "mach build binaries", but
automation couldn't benefit from that.
But after that experimentation, we've been switching to unified
compilation, which helped making builds faster by having the compiler
spend less time doing the same things in different files. But, it turns
out, it also made the pymake backend less efficient, because the pymake
backend still traverses directories without much parallelism, and now
many directories are only compiling one or two files, which means we're
not saturating the CPU when compiling. Which we do when using mozmake.
Recent try pushes show switching from pymake to mozmake gets our
automated builds (only the build part, excluding packaging, hg cloning,
etc.) down from ~2900 seconds to ~1900 seconds (and sometimes even down
to ~1700 seconds, for some reason). That's around a 35% build time drop.
Also noteworthy, upcoming build system changes that are expected to
further improve buils times, are likely to either break or make pymake
builds slower than they are now.
For all these reasons, please seriously consider switching to mozmake.
I have little sympathy for supporting an inferior and slower solution
for building Firefox. Accidentally using pymake could lead to a huge
loss in productivity (via unrealized gains) and is a giant foot gun.
I will be more than happy to nuke support for building with pymake as
soon as circumstances (read: automation) allow it.
Speak now or forever hold your peace.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
