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