This is great! A big thank you to all the folks who have worked for so long to
get us to this stage. I'm really looking forward to this work maturing and
extending to other platforms.
I've done a bit of testing on my workstation (14 core/28 thread i9, U.2
connected NVMe SSD, 64 GB DDR4 RAM) and got the following build times:
For -j28 (yes, -j28 is well into diminishing returns territory, but I wanted a
comparison of the best case scenarios for both backends):
| cold | top-level
| initial build | no-op rebuild
------------------------------------------
make | 8m 10s | 15s
tup | 6m 35s | 1.4s
And for -j8:
| cold | top-level
| initial build | no-op rebuild
------------------------------------------
make | 11m 33s | 15s
tup | 10m 52s | 1.4s
(To confirm: the rebuild numbers are the same for both -j28 and -j8.)
So a 20% reduction in build time on cold builds of a fresh tree with -j28, and
6% reduction with -j8. In addition to speeding up the build, Tup seems to
parallelize better which is great! Of course the highlight is the big reduction
in rebuild overhead which will make the edit-compile-run cycle a lot less
annoying (for me, 50s down to 37s after touching nsDocumentViewer.cpp,
rebuilding, and linking libxul, for both -j28 and -j8.)
These improvements, plus the promise of rarely having to clobber/figure out
which directories to rebuild in, put a big smile on my face. (Currently having
to turn off CARGO_INCREMENTAL, not being able to use sccache and other current
limitations, less so, but it's early days. :) )
A few notes for others trying this out (thanks cmanchester and mshal for the
help debugging some of these):
* Make sure you use:
--enable-build-backends=Tup
not:
--enable-build-backend=Tup
* You must be using an in-tree OBJDIR.
* MOZ_PARALLEL_BUILD isn't currently recognized, so you'll need to use
`mach build`s -j argument to control the parallel job count for now
( see https://bugzilla.mozilla.org/show_bug.cgi?id=1481441 )
mshal: I think you could cross-post this to dev-platform for wider testing. I
know there are a bunch of caveats (which people should be made aware of), but
since the initial teething issues I had were figured out I've so far had no
other problems building, or rebuilding with real code changes.
Jonathan
On 02/08/2018 16:34, Michael Shal wrote:
> Hi everyone,
>
>
> Tup is a modern build system that enables fast and correct builds. I'm pleased
> to announce the availability of Tup for building Firefox on Linux. Compared to
> Make, building with Tup will result in faster incremental build times and
> reduce
> the need for clobber builds. See the in-tree docs for details [1].
>
>
> We’re looking for some early adopters to try it out and let us know if it
> improves your workflow, or if you hit any blockers or barriers to adoption
> that
> keep you on the Make backend for now.
>
>
> Quick howto:
>
>
> You’ll need to install the Tup executable, as well as the nightly rust/cargo
> toolchain:
>
>
> cd ~/.mozbuild && mach artifact toolchain --from-build linux64-tup
> rustup install nightly
> rustup default nightly
>
> Your mozconfig needs to describe how to find the executable if it’s not in
> your
> PATH, and enable the Tup backend:
>
>
> export TUP=~/.mozbuild/tup/tup
> ac_add_options --enable-build-backends=Tup
>
>
> If you have any issues, feel free to file a bug blocking “buildtup” [2], or
> contact mshal or chmanchester in #build on IRC.
>
> [1] https://firefox-source-docs.mozilla.org/build/buildsystem/tup.html
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=buildtup
>
>
> Thanks!
>
> -Mike
>
>
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
