For new readers
----------------
Jumbo building is the Chromium implementation of "unity builds" where source files are merged for drastically improved compilation times.
For all readers:
----------------
The official test bot is still pending so the feature is still default off (can be enabled by setting use_jumbo_build = true in gn). There seems to be some issue with local mac builds ( https://crbug.com/716395 ) but I think Linux and Windows work fine.
Official Jumbo documentation:
https://chromium.googlesource.com/chromium/src/+/master/docs/jumbo.md
For old readers:
----------------
Since the last mail 10 days ago only core_generated has been added to jumbo builds on master. I haven't measured but that is a smallish target so it will only have saved 10 CPU minutes at most (out of 1000-2000 in the test configuration).
Some major targets are in the pipeline though: blink/modules (saving 60 CPU minutes), blink/core unit_tests (saving 59 CPU minutes), blink/modules unit_tests (saving 19 CPU minutes) and blink/platform (saving 35 CPU minutes).
HEADS UP
--------
To avoid having to exclude files and targets from jumbo compilation the files in the target has to compile when they are in the same translation unit. That means that names of functions, constants, classes must be unique in the gn target. This includes symbols in anonymous namespaces and static functions because the translation unit will no longer contain just one file.
Just to illustrate:
mycode/A.cpp
-----------------
#define Y Z
namespace { enum X { a, b }; }
static int Y() { return 1; }
mycode/B.cpp
-----------------
#define Y Z
namespace { enum X { a, b }; }
static int Y() { return 2;}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOT JUMBO COMPATIBLE if A.cpp and B.cpp are in the same target!
Most code use unique names so this does not matter a lot, but tests have turned out to be an exception. Thanks for all the people that have reviewed my renaming and general clean up of unit tests during the last week!
Official Jumbo documentation:
https://chromium.googlesource.com/chromium/src/+/master/docs/jumbo.md
The attached image illustrates the state of my local work branch as some kind of indication of what can be achieved (ignore the grey part).
/Daniel
P.S. Did I mention that I'm looking for volunteers, especially someone on Mac? D.S.
--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe: http://groups.google.com/a/chromium.org/group/chromium-dev
---You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/op.y3kyqoscrbppqq%40cicero2.linkoping.osa.
I would love to use shorter names for unittests, so instead of keeping the name uniqueness manually, I would propose to enclose everything in a file specific namespace, as below.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAHOzFDFHeq6s4QvgQoWrsX5j-W-0_00MD8PmFaOqxcHUbvVAQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAHOzFDFHeq6s4QvgQoWrsX5j-W-0_00MD8PmFaOqxcHUbvVAQ%40mail.gmail.com.
Very cool to see the build time improvements!One thing that makes me a bit sad is that we can't rely on unnamed namespaces to avoid naming collisions between unrelated files. How many of Chrome's source files are going to be in these jumbo compilation units? What's the granularity of each compilation unit?Also, is there any hope of realizing these build time improvements without using the jumbo compilation strategy? From the bug, it seems header parsing is a large component of build times. If we could somehow preparse and save the AST of individual headers (rather than saving all the headers in a giant precompile), would that help in any way?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACs%3DtyKh2CUUssVw4GTfpVyHwYWvdGk8WQDe3mtcoc9sKiOMHQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6FXJZv1ujsFmY3kTdtnfNPPrTkk0DGW%3DEpQO2%3D2EOCJ%3Dg%40mail.gmail.com.