[webkit-dev] [webkit-changes] [264332] trunk/Source

[Kirsling, Ross]

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.

Ross
________________________________
From: Geoffrey Garen <ggaren at apple.com>
Sent: Thursday, July 16, 2020 8:54:00 AM
To: Yusuke Suzuki <ysuzuki at apple.com>
Cc: Fujii, Hironori (SIE) <Hironori.Fujii at sony.com>; Darin Adler <darin at apple.com>; WebKit Development Mailing List <webkit-dev at lists.webkit.org>
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.

Thanks,
Geoff

On Jul 15, 2020, at 4:20 PM, Yusuke Suzuki <ysuzuki at apple.com<mailto:ysuzuki at apple.com>> 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.

-Yusuke

On Jul 15, 2020, at 7:33 AM, Alex Christensen <achristensen at apple.com<mailto:achristensen at apple.com>> 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 <fujii.hironori at gmail.com<mailto:fujii.hironori at gmail.com>> wrote:



On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig <weinig at apple.com<mailto:weinig at apple.com>> 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.
https://bugs.webkit.org/show_bug.cgi?id=214204#c25
Reducing header inclusion can easily cause build breakages for non-unified builds.
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 builds?

_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org<mailto:webkit-dev at lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200716/d562fae8/attachment.htm>