Better incremental builds - Tup backend available on Linux

Hi everyone, Tup is a modern build system that enables fast and correct builds. I'm pleased to announce the availability of Tup for building Firefox on Linux. Compared to Make, building with Tup will result in faster incremental build times and reduce the need for clobber builds. See the in-tree

Re: Rebuild speeds (Was: Re: JS compilation/evaluation APIs are now in #include "js/CompilationAndEvaluation.h")

On Thu, Aug 30, 2018 at 6:04 PM, Michael Shal wrote: > > > In this case, the 99:44 rebuild times look to be an artifact of how the > outputs of GenerateServoStyleConsts.py are consumed by a large chunk of the > Rust and C++ code. Attached is a graphviz .dot file for reference (

Re: Rebuild speeds (Was: Re: JS compilation/evaluation APIs are now in #include "js/CompilationAndEvaluation.h")

On Wed, Aug 29, 2018 at 11:36 AM, Boris Zbarsky wrote: > On 8/29/18 10:32 AM, Ted Mielczarek wrote: > >> so it's possible that there are things here that are artifacts of our tup >> build implementation. >> > > Worth keeping in mind, thank you. Would that possibly account for the >

Re: Is there a way to improve partial compilation times?

On Tue, Mar 7, 2017 at 5:40 PM, Randell Jesup wrote: > >On 07/03/17 20:29, zbranie...@mozilla.com wrote: > > > >> I was just wondering if really two days of patches landing in Gecko > should result > >> in what seems like basically full rebuild. > >> > >> A clean build

Re: Do we have some documents listing up when we need to touch CLOBBER?

On Fri, Dec 16, 2016 at 12:22 PM, Benoit Girard wrote: > I don't believe anyone has taken to time to go through the CLOBBER hg > history to find the causes and document them. That could be interesting. > > A while back I wrote a series of blog posts on clobber builds that

Taskcluster index: gecko.v1 routes are going away

Hi all, Builds will no longer publish to the gecko.v1 namespace in the Taskcluster index. Please use gecko.v2 for any future projects that need to find artifacts in Taskcluster. Feel free to contact me with any questions! Thanks, -Mike ___

Re: Decommissioning "dumbmake"

> > Also, .h dependency proliferation is a real problem for build system > performance, especially with the autogenerated mozilla-include.h (which > contains things from every AC_DEFINE in configure.in - an add AC_DEFINE, > invalidate everything). If you build the tips of mozilla-central from 24h

Re: Recent build time improvements due to unified sources

From: Neil n...@parkwaycc.co.uk There used to be a limitation that source files had to be in the VPATH. This limitation obviously does not apply to unified sources (the compiler will use the -I path to find the source.) so you shouldn't have a problem setting UNIFIED_SOURCES in a parent

Re: Unified builds

From: Gregory Szorc g...@mozilla.com Unified sources have probably saved sufficient CPU cycles across all of automation to more than offset having a non-unified build-only job. I'll defer to the Platform Team (Ehsan?) to request that from Release Engineering. How many CPU cycles would we