Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
> On Apr 29, 2021, at 9:06 PM, Tim Horton via webkit-dev 
>  wrote:
> 
> it is definitely highly annoying

It’s possible that where my thinking differs from others on this is that I 
don’t think shifting annoying work from one set of commits (the ones adding a 
new file) to a different set (the ones unknowingly adding need for a new 
include for non-unified builds) is a significant improvement. Adding more EWS 
bubbles has a cost.

Keep in mind that I am just as passionate as the next person about getting 
includes “right”. I’m just not sure that this would be a step in the right 
direction.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Tim Horton via webkit-dev


> On Apr 29, 2021, at 9:02 PM, Darin Adler  wrote:
> 
>> On Apr 29, 2021, at 9:01 PM, Tim Horton  wrote:
>> 
>> This is a huge problem for people on the Apple platforms using the Xcode 
>> projects. Nearly every time someone adds a file they have to add random 
>> headers to unrelated code.
> 
> OK, sorry, I must be out of touch with the rest of you about how difficult 
> this is. I’ve done that many times, and it was always easy for me.

I'm not saying it's hard (depending on your familiarity with the code that 
breaks, or if it's one of those 'using namespace' situations, or something even 
more subtle), but it is definitely highly annoying, and judging by the number 
of times I (and I'm sure others too) have had to explain what's up to other 
people it seems like "huge" is a only-maybe-slightly-overstated estimate :) 
Maybe others disagree!

> — Darin

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Tim Horton via webkit-dev


> On Apr 29, 2021, at 7:15 PM, Darin Adler via webkit-dev 
>  wrote:
> 
>> On Apr 29, 2021, at 12:04 PM, Ross Kirsling via webkit-dev 
>>  wrote:
>> 
>> Yeah, I think it's important to clarify that nobody is "using 
>> non-Unified-Source building for their development", at least to my 
>> knowledge. Being broken by the shifting sands of unified sources is an 
>> everybody problem (or at the very least an "everybody that builds via CMake 
>> problem", which is ultimately an everybody problem).
> 
> How is this a bigger problem in CMake than for people on the Apple platforms 
> who are using Xcode projects? Can we create greater parity between the two?

I don't follow. This is a huge problem for people on the Apple platforms using 
the Xcode projects. Nearly every time someone adds a file they have to add 
random headers to unrelated code. 

> — Darin
> ___
> 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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
> On Apr 29, 2021, at 9:01 PM, Tim Horton  wrote:
> 
> This is a huge problem for people on the Apple platforms using the Xcode 
> projects. Nearly every time someone adds a file they have to add random 
> headers to unrelated code.

OK, sorry, I must be out of touch with the rest of you about how difficult this 
is. I’ve done that many times, and it was always easy for me.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
> On Apr 29, 2021, at 12:04 PM, Ross Kirsling via webkit-dev 
>  wrote:
> 
> Yeah, I think it's important to clarify that nobody is "using 
> non-Unified-Source building for their development", at least to my knowledge. 
> Being broken by the shifting sands of unified sources is an everybody problem 
> (or at the very least an "everybody that builds via CMake problem", which is 
> ultimately an everybody problem).

How is this a bigger problem in CMake than for people on the Apple platforms 
who are using Xcode projects? Can we create greater parity between the two?

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread dpino via webkit-dev
On 2021-04-29 20:07, BJ Burg wrote:

> Given that there is some disagreement as to whether this is even a
> problem at all, perhaps we could try it out for a while. Diego, do you
> have the resources to set up an EWS bot in this configuration?
> 

Yes, we have two workers ready for this new EWS Non-Unified builder. The
target platform is WPE. There's also a patch with the configuration
changes at https://bugs.webkit.org/show_bug.cgi?id=225045 The patch is
currently being tested in the UAT.

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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Adrian Perez de Castro via webkit-dev
On Thu, 29 Apr 2021 19:04:55 + Ross Kirsling via webkit-dev 
 wrote:

> Yeah, I think it's important to clarify that nobody is "using
> non-Unified-Source building for their development", at least to my
> knowledge. Being broken by the shifting sands of unified sources is an
> everybody problem (or at the very least an "everybody that builds via CMake
> problem", which is ultimately an everybody problem).

This is pretty accurate. I do have a build directory configured manually
as non-unified so I can get its “compile_commands.json” to point tooling
at (mainly clangd, for code completion and linting), but actual builds I
do them with the “build-webkit” script.

Another situation in which I explicitly opt-in to non-unified builds is
around the time we make a release branch for the GTK and WPE ports; get
to solve the non-unified build issues and then land the patches in the
release branch as well. The goal here is to make sure that what we release
can be built non-unified, which means header includes and whatnot are
correct (at least for these ports) and we can have the confidence that
people doing cross-builds (where the set of files in each unified build
compilation unit can shift) will not have problems with the builds.

Before I did the above we used to have complaints and distributions
sometimes carrying odd patches playing whack-a-mole to get builds done
instead of properly fixing things.

Cheers,
—Adrián

 
> 
> From: Alex Christensen via webkit-dev 
> Sent: Thursday, April 29, 2021 11:03 AM
> To: Darin Adler 
> Cc: webkit-dev@lists.webkit.org 
> Subject: Re: [webkit-dev] New EWS Non-Unified builder
> 
> I don’t see the goal as “keep non-Unified-Source building” but rather 
> “prevent unrelated build fixes when we add another file later”.  Right now 
> when we add a new file we often have to sprinkle includes, declarations, and 
> other build fixes in files unrelated to the current change.  If we had a bot 
> building without unification we would be informed at the time we write the 
> problematic code.
> 
> > On Apr 29, 2021, at 9:55 AM, Darin Adler via webkit-dev 
> >  wrote:
> >
> > Given the issue is that there are people that are using non-Unified-Source 
> > building for their development, the best fix is to add post-commit and EWS 
> > builders for one of those platforms. I do not support the idea of adding an 
> > additional builder just to “keep non-Unified-Source building” if no 
> > actively-supported platform is not choosing that build style.
> >
> > Specifically, if Sony people are most affected by this, I suggest we find a 
> > way to add Sony PlayStation post-commit and EWS builders.
> >
> > I am not convinced that we should add some kind of abstract “correct 
> > compilation” that is a separate builder.
> >
> > — Darin
> > ___
> > 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
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


pgpstgQfzBoDJ.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-29 Thread Alex Christensen via webkit-dev
Thanks, David.  I think we’re on the same page now.

> On Apr 29, 2021, at 12:47 PM, David Benjamin  wrote:
> 
> Ah yes, that is confusing. Not quite. What's going on here is that we've 
> moved 3DES (and SHA-1 server signatures) under a fallback connection, so our 
> first connection won't advertise them, but on error the second one will. This 
> means that, for compatibility and security purposes, we do support 3DES. But 
> when you look at the ClientHellos, it'll look like we don't.
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ
>  
> 
Ah, yes.  Now I see that when connecting to https://3des.badssl.com/ Chrome 
will send a retry client hello with TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

> (By the way, it looks like, on my machine, Safari on Big Sur also supports 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.)
You are correct.  I overlooked that one, which upon closer inspection was right 
next to the other ones the whole time.

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


Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-29 Thread David Benjamin via webkit-dev
Ah yes, that is confusing. Not quite. What's going on here is that we've
moved 3DES (and SHA-1 server signatures) under a fallback connection, so
our first connection won't advertise them, but on error the second one
will. This means that, for compatibility and security purposes, we *do* support
3DES. But when you look at the ClientHellos, it'll look like we don't.
https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ

We do for more accurate measurement. In TLS, the client offers lists of
parameters, and then the server selects from that list based on its
negotiation criteria. That means if you simply measure the selected
parameters, you don't account for servers that supported other parameters
but preferentially picked this one, for some reason. This is also why
client tests like SSL Labs are very fast (they just read out the
ClientHello), while the corresponding server tests are very slow (they need
to probe server behavior in response to many ClientHellos and make guesses
about the negotiation criteria).

*Usually* the more straightforward measurement is good enough. It is an
upper bound[*], and everyone agrees TLS 1.1 is better than TLS 1.0, etc.
That AES is better than 3DES is also pretty well-established. However, from
looking at server behavior in the wild, we noticed there were a lot of
servers that had strange preference orders for 3DES and SHA-1 server
signatures. Servers that prefer 3DES but also support AES, while strange
and misconfigured, would *not* be broken by this removal. So, when
prevalent, it is useful to put them under fallback to get a more accurate
measurement.

This also means that, as you all evaluate 3DES for something similar, be
aware that a naive strategy may overcount the impact. So if your current
numbers are low enough, excellent. If they're too high, it is possible that
the true numbers are lower and the change is safer than it looks.

(By the way, it looks like, on my machine, Safari on Big Sur also supports
TLS_RSA_WITH_3DES_EDE_CBC_SHA.)

David

[*] Well, mostly. There's nothing stopping the server from implementing
some ridiculous selection logic like "if 3DES is present in the
ClientHello, pick AES-GCM, else, fail the connection". But that would be
ridiculous. :-)

On Wed, Apr 28, 2021 at 7:14 PM Alex Christensen via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> They are aware of this thread now, but I can’t comment on any future
> plans.  I do have a few quick questions, though.
>
> A quick glance at the client hellos sent by browsers shows this:
> Safari on Big Sur sends TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) and
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) in its supported cipher suites
> section of the client hello.
> Firefox 88 sends TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
> Chrome 90 sends no cipher suites with 3DES.
>
> This might be why Chrome measures 0.00% use of
> TLS_RSA_WITH_3DES_EDE_CBC_SHA - because it doesn’t advertise that it
> supports it.  It seems to me that you’ve already removed support for 3DES
> in Chrome.  What was the measured use of 3DES cipher suites in the release
> before you removed support?  We have measured slightly above 0.00% use in a
> browser that does send 3DES cipher suites in its client hellos.
>
> If you haven’t already removed support, how would one use it?  I’ll admit
> I haven’t gone through all the possibilities of renegotiation that TLS has.
>
> > On Apr 28, 2021, at 8:21 AM, Alex Christensen via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> >
> > Your measurement of 0.00% use in Chrome is exciting.
> >
> > Making this change would almost certainly not be a change in WebKit but
> I’ve reached out to the people who manage our crypto code.
> >
> >> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
> >>
> >>
> >> Looks like this change is clearly safe.
> >>
> >> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK,
> they're controlled by the operating system's TLS backend and crypto policy.
> 3DES has been disabled for a while now on modern systems, and users have
> not reported any compat issues, which is not surprising given your finding
> of 0.00%.
> >>
> >> Michael
> >>
> >>
> >> ___
> >> 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
>
> ___
> 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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Adrian Perez de Castro via webkit-dev
On Thu, 29 Apr 2021 15:56:31 + Don Olmstead via webkit-dev 
 wrote:

> When the Mac CMake build is in a working state I'd request an EWS that is 
> Non-Unified as well since Mac builds cover more code.

This would be a great addition, I agree. While I don't have a Mac around,
I can try and spare some cycles helping out with CMake Mac to get the build
in shape :)

Cheers,
—Adrian


> -Original Message-
> From: Alex Christensen via webkit-dev  
> Sent: Thursday, April 29, 2021 8:16 AM
> To: dpino 
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] New EWS Non-Unified builder
> 
> I’d be excited to have this.  Those build failures have been bothering me 
> ever since we started using unified builds.  We would have a way to see more 
> problems in our code that are currently hidden.
> 
> > On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
> >  wrote:
> > 
> > Hi everyone,
> > 
> > In Igalia we have been discussing the need of deploying a new builder 
> > which builds WebKit using non-unified sources, and we know that at 
> > least the folks at Sony are also in favor.
> > 
> > One side effect of Unified Source building is that it hides 
> > compilation errors. The kinds of errors that usually get hidden by 
> > unified builds are missing headers inclusions and missing definitions 
> > of functions declared inline; the latter being tricky to debug because 
> > it results in mysterious linker errors. This is caused by unified 
> > builds stashing several .cpp files together for compilation, so the 
> > definitions and header inclusions done in one “leak” into the others. 
> > As for missing header inclusion errors, a source file might include a 
> > header definition as a co-lateral effect of being stashed together 
> > with another file that indeed includes the missing header.
> > 
> > These hidden compilation errors may arise later at some point if 
> > unified source files are stashed together in a different manner.
> > 
> > The current situation is requiring periodical maintenance. You can 
> > check build fixes commits due to unified source compilation with:
> > 
> >$ git log --pretty=short --grep "Non-unified"
> > 
> > Here are some examples:
> >
> > https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=222652__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-e_2Uo6c$
> >  
> >
> > https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=222755__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-cnURaLI$
> >  
> >
> > https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=22
> > 1701__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_
> > y9h8CnFZ7s60jhM-qQl-arU$
> > 
> > A new builder which builds WebKit with non-unified Source will highly 
> > help to improve this situation. Compilation errors will be detected as 
> > soon as possible and will save a lot of time not only for the 
> > developers who are currently doing this manual maintenance but for 
> > anyone who would like to build WebKit, and may stumble on compilation 
> > errors accidentally introduced due to unified sources.
> > 
> > While correct compilation of the codebase can only be guaranteed with 
> > non-unified source builds, we do not propose switching the current EWS 
> > compilation builders to non-unified because it's slower and the EWS 
> > LayoutTests and API test bots use the products built by the EWS 
> > builders — we do not want to delay getting results from those. That's 
> > why we are proposing a new builder: it will run on parallel, resulting 
> > in no slowdown for the other EWS builders, which will keep using 
> > unified builds.
> > 
> > How this new builder will impact developers? The EWS LayoutTest bots 
> > take at least 1 hour to complete a build. We think that as long as 
> > this new EWS Non-Unified builder is within that time budget, this new 
> > EWS wont' slow down development speed.
> > 
> > Thoughts?
> > 
> > Best regards,
> > 
> > Diego
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/
> > webkit-dev__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjAC
> > a4ZTS_y9h8CnFZ7s60jhM-gSTmLtg$
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-gSTmLtg$
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


pgp8GrVzObtlu.pgp
Description: PGP signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org

Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Ross Kirsling via webkit-dev
Yeah, I think it's important to clarify that nobody is "using 
non-Unified-Source building for their development", at least to my knowledge. 
Being broken by the shifting sands of unified sources is an everybody problem 
(or at the very least an "everybody that builds via CMake problem", which is 
ultimately an everybody problem).

Ross

From: Alex Christensen via webkit-dev 
Sent: Thursday, April 29, 2021 11:03 AM
To: Darin Adler 
Cc: webkit-dev@lists.webkit.org 
Subject: Re: [webkit-dev] New EWS Non-Unified builder

I don’t see the goal as “keep non-Unified-Source building” but rather “prevent 
unrelated build fixes when we add another file later”.  Right now when we add a 
new file we often have to sprinkle includes, declarations, and other build 
fixes in files unrelated to the current change.  If we had a bot building 
without unification we would be informed at the time we write the problematic 
code.

> On Apr 29, 2021, at 9:55 AM, Darin Adler via webkit-dev 
>  wrote:
>
> Given the issue is that there are people that are using non-Unified-Source 
> building for their development, the best fix is to add post-commit and EWS 
> builders for one of those platforms. I do not support the idea of adding an 
> additional builder just to “keep non-Unified-Source building” if no 
> actively-supported platform is not choosing that build style.
>
> Specifically, if Sony people are most affected by this, I suggest we find a 
> way to add Sony PlayStation post-commit and EWS builders.
>
> I am not convinced that we should add some kind of abstract “correct 
> compilation” that is a separate builder.
>
> — Darin
> ___
> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread BJ Burg via webkit-dev
I'm in favor of a non-Unified EWS builder. It seems it would largely prevent 
the current situation where I have to add random headers to make my patch 
build, usually after the patch has been reviewed and revised. This "surprise, 
someone forgot a header" situation has no effect on our production builds, but 
it does affect engineering velocity quite a bit when multiple patches are being 
juggled.

Just as it's easier to fix style checker problems before committing, it's 
easier to address missing includes before committing. And I am not aware of a 
better way to improve the situation, other than to add some basic pre-commit 
checks.

Given that there is some disagreement as to whether this is even a problem at 
all, perhaps we could try it out for a while. Diego, do you have the resources 
to set up an EWS bot in this configuration?

BJ Burg (they/them)


> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> 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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Alex Christensen via webkit-dev
I don’t see the goal as “keep non-Unified-Source building” but rather “prevent 
unrelated build fixes when we add another file later”.  Right now when we add a 
new file we often have to sprinkle includes, declarations, and other build 
fixes in files unrelated to the current change.  If we had a bot building 
without unification we would be informed at the time we write the problematic 
code.

> On Apr 29, 2021, at 9:55 AM, Darin Adler via webkit-dev 
>  wrote:
> 
> Given the issue is that there are people that are using non-Unified-Source 
> building for their development, the best fix is to add post-commit and EWS 
> builders for one of those platforms. I do not support the idea of adding an 
> additional builder just to “keep non-Unified-Source building” if no 
> actively-supported platform is not choosing that build style.
> 
> Specifically, if Sony people are most affected by this, I suggest we find a 
> way to add Sony PlayStation post-commit and EWS builders.
> 
> I am not convinced that we should add some kind of abstract “correct 
> compilation” that is a separate builder.
> 
> — Darin
> ___
> 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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Darin Adler via webkit-dev
Given the issue is that there are people that are using non-Unified-Source 
building for their development, the best fix is to add post-commit and EWS 
builders for one of those platforms. I do not support the idea of adding an 
additional builder just to “keep non-Unified-Source building” if no 
actively-supported platform is not choosing that build style.

Specifically, if Sony people are most affected by this, I suggest we find a way 
to add Sony PlayStation post-commit and EWS builders.

I am not convinced that we should add some kind of abstract “correct 
compilation” that is a separate builder.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Alexey Proskuryakov via webkit-dev
Hi,

Do we have a post-commit non-unified builder? Starting with EWS wouldn't seem 
like a workable plan to me, as breakages would creep in anyway, and it's really 
hard to notice and isolate those from EWS results alone.

Giving all WebKit developers the responsibility to support more build 
configurations, particularly ones that are not required for any shipping 
product, terrifies me. I can see how unpredictable per platform build failures 
when files are added or removed are a downside of our unified builds. This 
doesn't seem like an intrinsic part of unified builds though. Can we do 
anything to make reshuffling the files more controlled, so that build failures 
happen predictably when one is willing to deal with them?

- Alexey

> 28 апр. 2021 г., в 11:45 PM, dpino via webkit-dev 
>  написал(а):
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> 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


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Don Olmstead via webkit-dev
When the Mac CMake build is in a working state I'd request an EWS that is 
Non-Unified as well since Mac builds cover more code.

-Original Message-
From: Alex Christensen via webkit-dev  
Sent: Thursday, April 29, 2021 8:16 AM
To: dpino 
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] New EWS Non-Unified builder

I’d be excited to have this.  Those build failures have been bothering me ever 
since we started using unified builds.  We would have a way to see more 
problems in our code that are currently hidden.

> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder 
> which builds WebKit using non-unified sources, and we know that at 
> least the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides 
> compilation errors. The kinds of errors that usually get hidden by 
> unified builds are missing headers inclusions and missing definitions 
> of functions declared inline; the latter being tricky to debug because 
> it results in mysterious linker errors. This is caused by unified 
> builds stashing several .cpp files together for compilation, so the 
> definitions and header inclusions done in one “leak” into the others. 
> As for missing header inclusion errors, a source file might include a 
> header definition as a co-lateral effect of being stashed together 
> with another file that indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if 
> unified source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can 
> check build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>
> https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=222652__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-e_2Uo6c$
>  
>
> https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=222755__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-cnURaLI$
>  
>
> https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=22
> 1701__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_
> y9h8CnFZ7s60jhM-qQl-arU$
> 
> A new builder which builds WebKit with non-unified Source will highly 
> help to improve this situation. Compilation errors will be detected as 
> soon as possible and will save a lot of time not only for the 
> developers who are currently doing this manual maintenance but for 
> anyone who would like to build WebKit, and may stumble on compilation 
> errors accidentally introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with 
> non-unified source builds, we do not propose switching the current EWS 
> compilation builders to non-unified because it's slower and the EWS 
> LayoutTests and API test bots use the products built by the EWS 
> builders — we do not want to delay getting results from those. That's 
> why we are proposing a new builder: it will run on parallel, resulting 
> in no slowdown for the other EWS builders, which will keep using 
> unified builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots 
> take at least 1 hour to complete a build. We think that as long as 
> this new EWS Non-Unified builder is within that time budget, this new 
> EWS wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/
> webkit-dev__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjAC
> a4ZTS_y9h8CnFZ7s60jhM-gSTmLtg$

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!t22i0IAUrm1zV3LCteGHgJVUHzashK_F9tqjACa4ZTS_y9h8CnFZ7s60jhM-gSTmLtg$
 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Alex Christensen via webkit-dev
I’d be excited to have this.  Those build failures have been bothering me ever 
since we started using unified builds.  We would have a way to see more 
problems in our code that are currently hidden.

> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> 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


[webkit-dev] Request for Position on Delegated Ink Trails

2021-04-29 Thread Mario Bianucci via webkit-dev
Hi webkit-dev,

This is a request for WebKit's position on Delegated Ink Trails.

It is currently in progress behind a flag in Chromium. There is no spec yet, 
but here is a link to the WICG explainer:
https://github.com/WICG/ink-enhancement

Thanks,
Mario Bianucci

(Apologies for the noise if you received this twice - I wasn't subscribed to 
webkit-dev earlier.)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread dpino via webkit-dev
Hi everyone,

In Igalia we have been discussing the need of deploying a new builder
which builds WebKit using non-unified sources, and we know that at least
the folks at Sony are also in favor.

One side effect of Unified Source building is that it hides compilation
errors. The kinds of errors that usually get hidden by unified builds
are missing headers inclusions and missing definitions of functions
declared inline; the latter being tricky to debug because it results in
mysterious linker errors. This is caused by unified builds stashing
several .cpp files together for compilation, so the definitions and
header inclusions done in one “leak” into the others. As for missing
header inclusion errors, a source file might include a header definition
as a co-lateral effect of being stashed together with another file that
indeed includes the missing header.

These hidden compilation errors may arise later at some point if unified
source files are stashed together in a different manner.

The current situation is requiring periodical maintenance. You can check
build fixes commits due to unified source compilation with:

$ git log --pretty=short --grep "Non-unified"

Here are some examples:
https://bugs.webkit.org/show_bug.cgi?id=222652
https://bugs.webkit.org/show_bug.cgi?id=222755
https://bugs.webkit.org/show_bug.cgi?id=221701

A new builder which builds WebKit with non-unified Source will highly
help to improve this situation. Compilation errors will be detected as
soon as possible and will save a lot of time not only for the developers
who are currently doing this manual maintenance but for anyone who would
like to build WebKit, and may stumble on compilation errors accidentally
introduced due to unified sources.

While correct compilation of the codebase can only be guaranteed with
non-unified source builds, we do not propose switching the current EWS
compilation builders to non-unified because it's slower and the EWS
LayoutTests and API test bots use the products built by the EWS builders
— we do not want to delay getting results from those. That's why we are
proposing a new builder: it will run on parallel, resulting in no
slowdown for the other EWS builders, which will keep using unified
builds.

How this new builder will impact developers? The EWS LayoutTest bots
take at least 1 hour to complete a build. We think that as long as this
new EWS Non-Unified builder is within that time budget, this new EWS
wont' slow down development speed.

Thoughts?

Best regards,

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