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> 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
>>>  <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 
>>> <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

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to