<div dir="ltr">It sounds like I was exaggerating how speculative modules are. On the other hand, until they are in use and demonstrating compile-time reductions in Chromium they are still speculative - we don't know how big a reduction they will give, how much work will be required to use them, how they will interact with goma builds, etc.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018 at 10:57 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018 at 10:42 AM Bruce Dawson <<a href="mailto:brucedawson@chromium.org" target="_blank">brucedawson@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think it was Churchill who said that "Jumbo builds are the worst form of build optimization, except for all the others."<div><br></div><div>The simple reality is that Chromium has a lot of translation units and there is a minimum (often a large minimum) cost to compiling each of these translation units. In order to make Chromium build times closer to reasonable we either need to dramatically reduce the number of translation units (jumbo) or dramatically reduce the cost of compiling each of these translation units.</div><div><br></div><div>Jumbo builds have some practical and philosophical problems but ultimately they work, and they work now, and they will get even better. Speculative efforts to reduce the per-translation-unit are, well, speculative. </div></div></blockquote><div><br>Not quite sure what you mean here - Clang header modules have been deployed across a variety of users (Apple initially shipped them to reduce compile time for Apple developers, especially around Cocoa.h, as I understand it - then Google's used them internally for protobufs & the like for a few years now). So it's not exactly speculative that these features exist, are implemented fairly robustly, and do offer improvements.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If and when modules improve our build times we can assess whether they should replace or coexist with jumbo builds, but until they are proven we need to proceed with what works today.</div><div><br></div><div>Making jumbo builds more maintainable through compiler changes appears to have an excellent cost/benefit ratio, and does nothing to stop us from pursuing other options in parallel. We will always continue to do non-jumbo builds, so our code will not be compromised by this effort.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018 at 10:19 AM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018 at 7:34 AM Nico Weber via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 10, 2018 at 10:27 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I haven't looked at the patches in detail - but generally a jumbo build feels like a bit of a workaround & maybe there are better long-term solutions that might fit into the compiler.</div></blockquote><div><br></div><div>People will use this, if we want them to or not (I have some influence in chrome land and wasn't able to talk them out of it, since it does provide huge benefits), and the workarounds needed without compiler support are gnarly.</div><div><br>So I think we might want to revisit our "you don't really want this" stance on this topic we've had historically and instead try to make this work well.</div></div></div></div></blockquote><div><br></div><div>I'm also revisiting my position on this. We've discussed unity build support in the past (I think Ubisoft proposed it), and at the time I felt that it was very backwards-facing. It's not a long term solution to reducing the overall cost of C++ compilation, and it can lead to creeping transitive dependencies between C++ files.<br></div><div><br></div><div>However, more than a year later, we have not produced a solution that is as easy to deploy and as compelling as unity builds are today. I think we need to seriously weigh cost of adding features to support unity/jumbo builds. The initial patches necessary to get things off the ground look small and relatively low-maintenance. They may be just the tip of the iceberg, so we need to gather more input, but I think it's worth a try.</div><div><br></div><div>FYI, my availability this week is low, so I don't expect to be able to participate more in this thread.</div></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>