I just did a no-op ./mach build binaries on my debug build on a Mac, and it took about 28 seconds.

$ time ./mach build binaries
 0:01.96 /usr/bin/make -j8 -s binaries
0:12.19 From ./dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.22 From ./dist/sdk: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.38 From ./dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:12.70 From ./dist/bin: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.09 From ./dist/idl: Kept 1155 existing; Added/updated 0; Removed 0 files and 0 directories. 0:13.11 From ./dist/include: Kept 3519 existing; Added/updated 0; Removed 0 files and 0 directories. 0:20.46 From _tests: Kept 11158 existing; Added/updated 0; Removed 0 files and 0 directories.
Your build was successful!

real    0m28.291s
user    0m8.685s
sys     0m4.178s

Do you have any plans to bring down the overhead? Do you know where this overhead is coming from?

Thanks!
Ehsan


On 2013-10-01 9:17 PM, Mike Hommey wrote:
Hi,

If you've read the "You want faster builds, don't you" thread, you may
know that some build improvements have recently landed.

I just landed the most important part of it all, and we should now be in
a much better place, but, as I'm very cautious, and as this is
incremental improvements to an existing complex build system that is
hard to improve all at once without some subtle breakages, this is
opt-in. It also doesn't work with pymake because of bug 918652.

At this point, you probably want to know what it is and how to use it.

There is now a new target for incremental C/C++ rebuilds. What this means
is, you build once like usual. Then after you do your C/C++ changes,
instead of:
   - mach build or make -C objdir, which takes forever
   - mach build subdirectory/of/the/changes, which sometimes rebuilds
     toolkit/library, sometimes not, depending what you're rebuilding.
   - make -C objdir/subdirectory/of/the/changes && make -C
     objdir/toolkit/library, which may actually not be enough.
you can now do:
   - mach build binaries
     or
   - make -C objdir binaries

It will rebuild your changes and everything that needs rebuilding because
of them. It will also do that quickly.

There are a few caveats:
- it only handles C/C++ changes, including headers. It doesn't handle js
   modules, chrome data, etc.
- it does *not* handle changes to xpidl, webidl, ipdl. yet. There's a
   followup for this to happen: bug 921309.
- it doesn't handle changes to nss, nspr, icu or ffi. If you do changes
   there, you still need to run a normal build.
- it doesn't work without doing a normal build first.
- while it shouldn't break your builds, it might subtly skip what you
   would expect it to build. If it does, please file a bug or contact me
   on irc. You can still use the old ways until your issues are fixed.

Something else that I landed today is support to skip directories during
a normal build when they're not relevant to the build. As always, I'm
overcautious and this is opt-in. If you want to opt-in for this (and
future experimental improvements), please add "export
MOZ_PSEUDO_DERECURSE=1" to your mozconfig. Except if you're using
pymake, sadly. The more people test those experimental improvements, the
quicker they can become the default for everyone.

For those interested in the gory details, I'll post some on my blog within
the next few days.

Mike
_______________________________________________
dev-builds mailing list
dev-bui...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds


_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to