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 <gga...@apple.com> Sent: Thursday, July 16, 2020 8:54:00 AM To: Yusuke Suzuki <ysuz...@apple.com> Cc: Fujii, Hironori (SIE) <hironori.fu...@sony.com>; Darin Adler <da...@apple.com>; WebKit Development Mailing List <webkit-dev@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 <ysuz...@apple.com<mailto:ysuz...@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 <achristen...@apple.com<mailto:achristen...@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.hiron...@gmail.com<mailto:fujii.hiron...@gmail.com>> wrote: On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig <wei...@apple.com<mailto:wei...@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@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
