On Mon, Aug 25, 2014 at 12:24:53PM -0700, Eric Rescorla wrote: > On Mon, Aug 25, 2014 at 8:37 AM, Gregory Szorc <g...@mozilla.com> wrote: > > > On 8/22/14 9:08 AM, Ehsan Akhgari wrote: > > > >> Unfortunately I don't really understand the reasons behind this, but if > >> you > >> use this command, please know that it doesn't work properly any more, even > >> if it seems to work in some cases. AFAICT the workarounds are either > >> doing > >> a full build or ./mach build binaries (I don't really know what things the > >> latter supports these days.) > >> > >> Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1055204 for the > >> discussion about this. > >> > > > > I'd like to re-frame this a bit. > > > > How fast do "no-op" / light builds need to be for |mach build > > <subdirectory>| to not exist? > > > > The reason people do partial builds is because the full tree build isn't > > fast enough: if full tree builds completely instantaneously, we wouldn't > > need partial tree builds. People like |mach build binaries| because it's > > fast and gets the job done. Regular no-op builds currently take ~50s on my > > MBP. That's ~50s of overhead. We can do better. > > > > As a build peer, partial tree builds are a thorn in my side. We have to > > consider and try to support them. It's non-trivial. I'd prefer if they were > > unsupported and went away. > > > > What amount of overhead for full builds is tolerable before we can > > officially kill support for partial builds? While I'd like to say we can > > deliver "instantaneous," that's not realistic unless we actively invest in > > it. I wrote patches over the weekend that decrease no-op builds from ~50s > > to ~37s. It's noticeably faster. I think we could get it down to 20s with a > > few days of work. 10s with a few weeks of work. Any faster will likely > > require a non make-based build backend. > > > > I'm going to say that 15s no-op build times is fast enough that we can > > kill partial tree building support, or at least cripple it so it doesn't do > > so much. Keep in mind that |mach build binaries| today is ~6.5s, and that's > > without modifications. Modify a .cpp file affecting libxul and you are up > > to ~12.5s. > > > I experience much longer build times on my Macbook Air: > A no-op ./mach build binaries is 44 seconds.
That can't be a no-op. There must be something it's compiling and it must be linking libxul. And yes, that is not going to magically get faster than the time it takes to link libxul. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
