On Thu, Mar 27, 2014 at 9:38 AM, Gregory Szorc <[email protected]> wrote: > 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.
Yes. Once mozmake is in production and we are confident in it we should terminate our pymake experiment. - Kyle _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
