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

On Thu, Jul 16, 2020 at 4:14 pm, Darin Adler wrote: Let’s stop doing it that way. Just compile the files and have #if inside the file. I removed all conditional source files from the Xcode build system. Let's do the same for the CMake build system. — Darin I agree we should do this.

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

> On Jul 16, 2020, at 3:33 PM, Adrian Perez de Castro wrote: > > enabling/disabling features changes the set of source files to > build, which results in different source files being #included from each > unifier source compilation unit. Let’s stop doing it that way. Just compile the files and

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

On Thu, 16 Jul 2020 15:01:14 -0700, Darin Adler wrote: > > On Jul 16, 2020, at 2:28 PM, Adrian Perez de Castro > > wrote: > > > > It is not feasible to test unified builds for all the possible combinations > > of > > target architectures and set of features enabled at build time (there is a >

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

Hi, On Fri, 17 Jul 2020 06:52:54 +0900, Fujii Hironori wrote: > I'm glad to hear various opinions. Slack still can't beat mailing lists for > technical discussions. Aye, in my experience mailing lists are better because having to write down thoughts in a slightly more structured way (in a mail

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

> On Jul 16, 2020, at 2:28 PM, Adrian Perez de Castro wrote: > > It is not feasible to test unified builds for all the possible combinations of > target architectures and set of features enabled at build time (there is a > combinatorial explosion of configurations). Keeping non-unified builds in

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

I'm glad to hear various opinions. Slack still can't beat mailing lists for technical discussions. On Fri, Jul 17, 2020 at 6:37 AM Adrian Perez de Castro wrote: > Also, some packagers used to carry assorted downstream patches for build > issues related to unification build which have not been

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

I forgot to mention one tidbit... On Fri, 17 Jul 2020 00:28:53 +0300, Adrian Perez de Castro wrote: > Hello everybody, > > On Thu, 16 Jul 2020 12:57:01 -0700, Darin Adler wrote: > > > On Jul 16, 2020, at 12:54 PM, Kirsling, Ross > > > wrote: > > > > > > Non-unified build fixes are done to

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

Hello everybody, On Thu, 16 Jul 2020 12:57:01 -0700, Darin Adler wrote: > > On Jul 16, 2020, at 12:54 PM, Kirsling, Ross wrote: > > > > Non-unified build fixes are done to support *all* platforms, because > > sudden unification shifts can happen anywhere. > > I’m not sure that benefit is worth

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

> On Jul 16, 2020, at 12:54 PM, Kirsling, Ross wrote: > > Non-unified build fixes are done to support *all* platforms, because sudden > unification shifts can happen anywhere. I’m not sure that benefit is worth the additional code churn. I understand that it’s frustrating to run into a

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

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

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

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

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

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

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

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

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 , I’d like to > understand why we have two different compilation models supported in > WebKit. Is there a reason both need to be

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

> On Jul 14, 2020, at 2:38 PM, Simon Fraser wrote: > > Could someone educate me about ? When should I use this > instead of individual wtf headers? Forward.h is analogous to forward-declaring a class ('class IntPoint;' instead of ‘#include “IntPoint.h”'), but it works for many often-used

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

Could someone educate me about ? When should I use this instead of individual wtf headers? Simon > On Jul 14, 2020, at 2:32 PM, Sam Weinig wrote: > > While I don’t want to take away from what Darin is saying here about correct > usage of forward declaration and , I’d like to understand why

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

While I don’t want to take away from what Darin is saying here about correct usage of forward declaration and , 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? - Sam > On Jul 14, 2020, at

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

> On Jul 14, 2020, at 10:40 AM, Darin Adler wrote: > > We need to be cautious about adding header includes to other headers. Adding > includes to .cpp files is likely fine and not a deeply consequential > decision, but adding to headers is something that can have a massive effect > on build

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

We need to be cautious about adding header includes to other headers. Adding includes to .cpp files is likely fine and not a deeply consequential decision, but adding to headers is something that can have a massive effect on build times over time. > On Jul 13, 2020, at 10:44 PM,