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.
:-)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
