On 2014-08-25, 6:17 PM, Mike Hommey wrote:
On Mon, Aug 25, 2014 at 06:06:17PM -0400, 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. :-)
Well, reading this thread, it doesn't seem mach build dir is broken for
the use people make of it, which is to build in a single directory. What
people want apparently, is more being able to build a single file or set
of files, more than a directory and its subdirectories.
And ninja is not going to change anything for people wanting to rebuild
a few files when changing a header. In fact, it would likely make things
harder for them.
Not at all, quite to the contrary. You can build specific targets with
ninja just fine, and it's non-recursive and fast and all. :-)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
