----- Original Message ----- > From: "Gregory Szorc" <[email protected]> > To: "Ehsan Akhgari" <[email protected]>, [email protected] > Sent: Monday, August 25, 2014 8:37:42 AM > Subject: Re: PSA: ./mach build <subdirectory> doesn't work reliably any longer > > 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.
Even if a full no-op build took no time, partial builds are still useful. Often my workflow looks something like this: change files in directory D rebuild only D, get a list of errors to fix ...iterate until no more errors try to rebuild a few related directories, fixing errors there then rebuild the entire tree, hopefully without errors Often the changes to directory D are to header files that are included all over the tree. If I could only do full rebuilds, I would have to wait for a bunch of unrelated files to compile before I could see if the directory I'm interested in works. Then, if fixing an error required making a change to one of the header files again, I would have to wait for a ton of files to recompile again. A process that would have taken 20 minutes could be drawn out into an hour. This happens really often when changing the JS engine or xpconnect, since files like jsapi.h, jsfriendapi.h, and xpcpublic.h are included almost everywhere. > 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 hope you mean "kill them in mach, but still allow make -C to work". Otherwise this would be really disruptive. As an aside, I'm pretty happy with the way mach works now. But, while it was stabilizing, it probably me cost several days figuring out how to make my old workflows work again. From a different thread, it sounds like dbaron and others have had similar experiences. Across all our developers, that's a lot of time. If there are more major breaking changes to the build system coming down the line, it would be much better to ensure that the new system serves developers needs before breaking the old one. We generally have a "no regression" policy for the code we ship; it seems like we should do the same thing for the build system. -Bill _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
