> * You must be using an in-tree OBJDIR. Does it handle multiple in-tree objdirs? E.g. I have d64 (debug), o64 (opt), etc.
Nick On Tue, Aug 7, 2018 at 11:18 PM, Jonathan Watt <jw...@jwatt.org> wrote: > 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 >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
