On 8/25/14 3:06 PM, Ehsan Akhgari wrote:
On 2014-08-25, 4:49 PM, Gregory Szorc wrote:
On 8/25/14 1:15 PM, L. David Baron wrote:
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
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

A similar problem that's been bugging me lately is that if I use
"mach build binaries" and it hits a compiler error, if I go fix the
error and rerun "mach build binaries", I have no idea how long I
need to wait to see if I even fixed the error successfully, since
the rebuild builds things in a different order.  The
mostly-deterministic order that the build system used to provide was
an advantage for that case.

This is an unfortunate side-effect of how make works compounded with our
use of make to achieve fast builds with |mach build binaries|.

I don't see an easy way around the problem while still using make. I
think we're on the right course of action, which is to invest in getting
the tree to build with "not make." Unfortunately, build staffing hasn't
been reliable in the past 6+ months, so our trajectory towards this goal
isn't as fast as you may prefer. That being said, glandium has done
great things in the past few weeks related to C++ compilation. We're
closer than ever to being able to e.g. generate Ninja and Tup files for
building binaries.

So can we at least agree to keep ./mach build dir working until when we
have Ninja support?  Since if we ever get to that point, most of the
performance problems with the build system would have been fixed anyway.

Nit: most of the performance problems with the *C/C++ part of* the build system would have been fixed anyway.

Currently compiling/linking is pretty efficient and most of our pains are from other things, notably XPCOM manifest updating, jar.mn processing, and the long tail of custom rules in Makefile.in. There's a good chance we may adopt a hybrid build system where we're emitting e.g. Ninja files for the C++ bits and falling back to make for everything else.

Let me talk to glandium before committing to anything. I do hear your collective pain and want to ease it.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to