Non-unified build fixes are done to support *all* platforms, because sudden 
unification shifts can happen anywhere. We can't currently perform a full 
non-unified build on Mac since the CMake build only works up through JSC, so 
Sony and Igalia have been performing this maintenance by hand on Windows and 
Linux for years. It is for this reason that one is unlikely to encounter 
unification shift issues via EWS.

Tips for how to make better build fixes are helpful, but these build fixes 
can't go anywhere until we have a bot to identify missing includes and such as 
they arise.

From: Geoffrey Garen <>
Sent: Thursday, July 16, 2020 8:54:00 AM
To: Yusuke Suzuki <>
Cc: Fujii, Hironori (SIE) <>; Darin Adler 
<>; WebKit Development Mailing List <>
Subject: Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

The original question was, as I understood it, was do we need to support 
non-unified builds as an essential requirement for a given port, and if so, why?

I’d like to finish answering that question, before we wonder off-topic and 
consider whether supporting non-unified builds as an optional way to improve 
our workflow is a good idea.


On Jul 15, 2020, at 4:20 PM, Yusuke Suzuki 
<<>> wrote:

And I agree, keeping non-unified build sane is quite useful.
In addition to the benefit described by Alex, this also allows CMake to 
generate sane compile_commands.json, so that my completion in Neovim works 
better in cpp files,
and I think this compile_commands.json is also used in several clang-related 
toolings too.

I think we should have a bot maintaining it.


On Jul 15, 2020, at 7:33 AM, Alex Christensen 
<<>> wrote:

I think it is still quite useful to fix non-unified builds.  Otherwise adding a 
file usually involves many unrelated build fixes.

On Jul 14, 2020, at 5:25 PM, Fujii Hironori 
<<>> wrote:

On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig 
<<>> wrote:
While I don’t want to take away from what Darin is saying here about correct 
usage of forward declaration and <wtf/Forward.h>, I’d like to understand why we 
have two different compilation models supported in WebKit. Is there a reason 
both need to be supported? Can we remove one?

I also want to know that. Does anyone still need non-unified builds?

I introduced other unnecessary header inclusion, and Darin asked me to fix it.
Reducing header inclusion can easily cause build breakages for non-unified 
So, I fixed non-unified build breakage in r264332 and r264333 as the 
preparation for that.
Non-unified builds was more broken than I expected. Does anyone still need it?
Should we maintain non-unified builds until C++20 modules will nullify unified 

webkit-dev mailing list<>

webkit-dev mailing list<>

webkit-dev mailing list<>

webkit-dev mailing list

Reply via email to