> On Sep 8, 2022, at 5:41 AM, Adrian Perez de Castro via webkit-dev
> wrote:
> On Thu, 08 Sep 2022 02:27:53 + Alexey Proskuryakov via webkit-dev
> wrote:
>> Without non-unified EWS, or anyone fixing non-unified build manually:
>> - a smaller number of patches gets rejected for breaking exi
On Thu, Sep 8 2022 at 03:00:00 PM +0300, Adrian Perez de Castro
wrote:
My laptop has 20 GiB of memory and a debug build in non-unified mode
links
just fine with either LLD or Mold (I haven't used the GNU linker for
months).
Something smells fishy with your setup.
I haven't changed the defaul
Hi list,
On Thu, 08 Sep 2022 02:27:53 + Alexey Proskuryakov via webkit-dev
wrote:
> Ross, I didn't mean any disrespect.
> I absolutely agree that this issue is not about the project supporting
> multiple platforms.
> What I disagree with is the statement that omitting includes necessary
Hi Michael,
On Wed, 07 Sep 2022 12:41:00 -0500 Michael Catanzaro via webkit-dev
wrote:
> On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro
> wrote:
> > I would go even further and consider enabling unified builds only in
> > DEVELOPER_MODE (for CMake ports). For non-developer builds
If I may add,
On Thu, 2022-09-08 at 02:27 +, Alexey Proskuryakov via webkit-dev
wrote:
> With non-unified EWS:
> - many patches get rejected for breaking it;
> - it's easy for the patch author to add the includes.
- over time, by force of habit /less patches break/, as contributors
become m
rg> >
Cc: webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
mailto:webkit-dev@lists.webkit.org> >
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder
I can't speak for everyone, but the reason why I haven't been responding was
that the discussion
_
From: Alexey Proskuryakov via webkit-dev
Sent: Wednesday, September 7, 2022 5:05:40 PM
To: Michael Catanzaro
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder
I can't speak for everyone, but the reason why I haven't been resp
I can't speak for everyone, but the reason why I haven't been responding was
that the discussion went in circles, and didn't address the concerns raised.
There is new evidence showing that maintaining the non-unified build is very
hard. We knew that from the start, which is why the plan was to
At this point I would just go ahead and create the EWS bot. Even if
it's not going to be a default build configuration, we're still wasting
a bunch of time and effort to keep it working, and the EWS would help
fix that.
___
webkit-dev mailing lis
On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro
wrote:
I would go even further and consider enabling unified builds only in
DEVELOPER_MODE (for CMake ports). For non-developer builds,
compilation time is much less important than limiting RAM usage to
reasonable levels. Using ninja'
Hi again,
On Fri, 02 Sep 2022 15:02:05 +0300 Adrian Perez de Castro
wrote:
> I have picked this message from Ryosuke because I want to explicitly address
> a misjudged metric on the effort it takes to address non-unified build issues
> after patches that break them have landed -- but my comment
Hello,
I have picked this message from Ryosuke because I want to explicitly address
a misjudged metric on the effort it takes to address non-unified build issues
after patches that break them have landed -- but my comments apply to the
discussion in general.
On Wed, 01 Jun 2022 16:39:39 -0700 Ryo
On 6/8/22 02:40, Elliott Williams via webkit-dev wrote:
>
>> On Jun 7, 2022, at 10:27, Olmstead, Don via webkit-dev
>> wrote:
>>
>> If we wanted to try any tooling around identifying when an include or
>> forward declaration should be used we need a functioning non-unified build.
>> We could tr
On 6/7/22 01:39, Geoffrey Garen via webkit-dev wrote:
>> As such, I also think that the non-unified EWS being green should not be a
>> blocker to landing a patch. But I think having it there for information will
>> help the situation. At minimum, even if every engineer simply ignores the
>> no
> On Jun 7, 2022, at 10:27, Olmstead, Don via webkit-dev
> wrote:
>
> If we wanted to try any tooling around identifying when an include or forward
> declaration should be used we need a functioning non-unified build. We could
> try IWYU on the codebase,
> https://github.com/include-what-yo
I agree with everything Mark said in his reply I just wanted to add another
benefit of having a non-unified build specifically to support build time
optimization.
> > 2) In my contributions, I don’t just want to add missing includes, I want
> > to remove unnecessary ones taking full advantage o
If it's useful as a data point, in Gecko we used not to care about
non-unified builds. This worked kind of ok, because the file
arrangements were mostly deterministic by directory. However, folks
running with weird build configurations always ended up hitting these
issues (and they might not kn
> On Jun 6, 2022, at 1:09 PM, Olmstead, Don wrote:
>
> If it isn’t it should be considering how many times I’ve had a cq- come from
> an AppleWin build that is in no way affected by my patch.
Yes, we have a problem with that AppleWin bot, and it’s one that bothers me
quite a bit, but I don’t w
] Deployment of new EWS Non-Unified builder
As such, I also think that the non-unified EWS being green should not be a
blocker to landing a patch. But I think having it there for information will
help the situation. At minimum, even if every engineer simply ignores the
non-unified EWS, it also makes
> As such, I also think that the non-unified EWS being green should not be a
> blocker to landing a patch. But I think having it there for information will
> help the situation. At minimum, even if every engineer simply ignores the
> non-unified EWS, it also makes it easier for someone trying to
I think Ross’ point about supported ports being bitten by missing includes is
valid. I also agree that it can take more time (possibly a lot more time) for
an engineer stepping on the issue later in time to fix the missing includes vs
the original author fixing it if a non-unified EWS points ou
Yes, I don’t oppose adding another EWS bot, and I was not trying to argue
against that proposal. I did intend to express my disagreement with many points
made in follow-up replies that seem quite wrong to me.
Three other thoughts:
1) Even though I don’t object to adding a new bot, I will say th
"Supported configurations" may indeed be too tricky of a concept to pin down,
but I believe Diego explained quite thoroughly how the central issue here would
be every bit as relevant in a world where we only care about standard Mac
builds.
If FooBar.cpp and FooBaz.cpp need the same 10 includes,
Here’s my view:
Long ago we agreed that we’ll ask WebKit contributors to keep builds working
that have EWS bots, and not other configurations. As far as I can tell, nothing
has changed that invalidates that strategy and we should stick with it.
I do not agree that the statement that “all projec
On Thu, Jun 2, 2022 at 4:28 AM Claudio Saavedra via webkit-dev
wrote:
>
> On Wed, 2022-06-01 at 16:39 -0700, Ryosuke Niwa via webkit-dev wrote:
> > One day per month for one beginner sounds like a really low
> > maintenance cost compared to having every WebKit developer fix non-
> > unified builds
On Wed, 2022-06-01 at 16:39 -0700, Ryosuke Niwa via webkit-dev wrote:
> One day per month for one beginner sounds like a really low
> maintenance cost compared to having every WebKit developer fix non-
> unified builds at all times.
I'm sorry, but this is not about having "every WK developer fix
Hi Alexey,
On 6/2/22 06:26, Alexey Proskuryakov wrote:
> Hi,
>
> I'm not sure if we have a consensus on whether it is a project goal to keep
> non-unified build working at all times. As discussed last year, setting up
> post-commit bots is a pre-requisite for having EWS, so this part is reso
On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro
wrote:
I would go even further and consider enabling unified builds only in
DEVELOPER_MODE (for CMake ports). For non-developer builds,
compilation time is much less important than limiting RAM usage to
reasonable levels. Using ninja'
ebkit-dev@lists.webkit.org"
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder
On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev
mailto:webkit-dev@lists.webkit.org>> wrote:
I feel like this has been discussed adequately in the past, but one more time
for g
On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev <
webkit-dev@lists.webkit.org> wrote:
> I feel like this has been discussed adequately in the past, but one more
> time for good measure:
>
> Any two platforms which don't build the exact same set of files will
> undergo unification differ
Ross
Cc: dpino ; webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder
Hi,
I'm not sure if we have a consensus on whether it is a project goal to keep
non-unified build working at all times. As discussed last year, setting up
post-commit bots is
20, 2022 9:17:56 PM
To: webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
mailto:webkit-dev@lists.webkit.org> >
Subject: [webkit-dev] Deployment of new EWS Non-Unified builder
Hi,
Last year we started a thread to discuss the possibility of deploying a
new EWS bot t
On Sat, May 21 2022 at 07:10:30 AM +, "Kirsling, Ross via
webkit-dev" wrote:
This is wonderful news—thanks Diego!
Agreed.
I would go even further and consider enabling unified builds only in
DEVELOPER_MODE (for CMake ports). For non-developer builds, compilation
time is much less import
This is wonderful news—thanks Diego!
Ross
From: dpino via webkit-dev
Sent: Friday, May 20, 2022 9:17:56 PM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Deployment of new EWS Non-Unified builder
Hi,
Last year we started a thread to discuss the
Hi,
Last year we started a thread to discuss the possibility of deploying a
new EWS bot that builds WebKit with Non-Unified sources [1]. This thread
explains the technical reasons why a non-unified build bot is desirable.
If you're aware of the problems introduced by unified sources
compilation, s
35 matches
Mail list logo
