<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 22, 2018 at 4:19 PM, Jens Widell via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, May 22, 2018 at 2:04 PM, Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br>
> Hi Jens,<br>
><br>
> On Fri, May 18, 2018 at 9:17 AM, Jens Widell via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> Hi all,<br>
>><br>
>> I'd like to summarize this thread (so far) and try to agree on a way forward.<br>
>><br>
>> First, we had an interesting discussion on unity building in general,<br>
>> or perhaps rather other, more "modern", ways to achieve the same or<br>
>> similar effects. In the short term, this discussion is mostly<br>
>> academic; the fact is that the Chromium project already has a unity<br>
>> build configuration as described at the start of this thread, and it's<br>
>> in "production" use. We're proposing these changes to Clang to reduce<br>
>> an existing maintenance cost.<br>
>><br>
>> Second, we've had two principal proposed ways to support unity builds in Clang:<br>
>><br>
>> 1) The "custom" but ultimately pretty trivial, in terms of changes to<br>
>> the core Clang code, way implemented by my proof-of-concept patch.<br>
>><br>
>> 2) An thus-far nowhere implemented way built on top of Clang's support<br>
>> for C++ modules.<br>
>><br>
>> I'm not qualified to tell how much work (2) would be, how big the<br>
>> changes to Clang would be, or how much of a maintenance burden this<br>
>> would be on the Clang project, but it sounds more complicated to me,<br>
>> so I'm inclined to think that (2) > (1) in all of those metrics.<br>
>><br>
>> I will also not be able to implement (2), because of the inevitably<br>
>> limited nature of time.<br>
>><br>
>> So, if I don't receive push-back here (e.g. someone committing to work<br>
>> on (2)), I'll proceed to submit patches for (1).<br>
><br>
> My concern is whether (1) would carry its own weight. Even though it's<br>
> fairly simple, would it be useful enough for projects besides Chromium<br>
> that it warrants the complexity of having it in the tree? Are there<br>
> other problems it would need to handle, like explicit template<br>
> instantiation declarations and definitions that weren't intended to<br>
> end up in the same translation unit.. I feel there could be lots of<br>
> problems.<br>
<br>
</div></div>So, we/I never really intended for the Clang extension to completely<br>
fix all issues that are or can be caused by combining source files<br>
into a single compilation unit. Sure, that would be awesome to have,<br>
but the intention was something that addressed some major annoyances,<br>
and thus makes the unity build configuration less burdensome to<br>
support.<br>
<br>
The complexity of a solution, any solution, that addresses all<br>
possible issues may well be unfeasible to have in the Clang source<br>
tree. I don't have such a solution to look at, and never intended to<br>
produce one, so I can't really say.<br>
<br>
I don't really know about other projects. Chromium certainly isn't the<br>
first project to use unity builds, but I don't know whether other<br>
projects would find a Clang extension useful, or if they've worked<br>
around the issues in other ways. The Chromium code base is in certain<br>
ways rather painful to apply unity builds to, which would not<br>
necessarily apply to all code bases, but also surely isn't<br>
particularly unique.</blockquote><div><br></div><div>Anecdotally, unity builds seem to be used most often on proprietary codebases (eg in the games industry) so they're somewhat hidden.  Reid mentioned previous discussions with Ubisoft(?) earlier in this thread- perhaps we can dig up some contacts and reach out to them?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> But if it's possible to implement this in a very simple and clean way<br>
> (that also handles static functions and variables the same as<br>
> anonymous namespaces) that works well for many projects? If so it<br>
> seems hard to argue against it.<br>
<br>
</span>I think my proof-of-concept is fairly simple and clean, in particular<br>
the parts that's in Clang and not the plugin.<br>
<br>
It does not handle static functions or variables. Would that be a<br>
specific requirement for this extension to be acceptable? Would<br>
anything else?<br>
<span class=""><br>
> For Chromium, part of me hopes we could do something better though.<br>
> Maybe using proper modules, or maybe just by restructuring parts of<br>
> Blink.<br>
<br>
</span>And I'm of course in no way against that.<br>
<br>
But we've had a huge compilation time issue for a long while. And<br>
we've been using a very effective solution to address that issue for<br>
quite some time. At this point we're dealing with the maintenance cost<br>
of the existing solution. Any discussion about alternative solutions<br>
ought to happen in parallel with discussions about improving the<br>
existing solution, I think.<br></blockquote><div><br></div><div>Migrating a large project like Chromium to modules sounds interesting, but would be an incredible amount of work with relatively high risk of failure.  I have been looking for field reports of teams using Clang's C++ modules but have only been able to find relatively small experiments that I would not like to extrapolate too far from.  And our existing build tools are unlikely to work (ccache, icecc etc), so there's a large productivity hump to get over before we would ever be able to see any benefit.  </div><div><br></div><div><br></div><div>-Mostyn.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<br>
Jens<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Mostyn Bramley-Moore<div><div>Vewd Software</div><div><a href="mailto:mostynb@opera.com" target="_blank">mostynb@vewd.com</a></div></div></div></div></div></div></div></div></div></div>
</div></div>