Re: [webkit-dev] Unified sources have broken our #include hygiene

[Don . Olmstead]

This was actually something I wanted to bring up at the contributors meeting 
especially since I was bit by this recently with some CMake changes that busted 
WPE.

It would be nicer to move our tooling to clang. Include what you use is 
something I think would be of great use as well. CMake has built in support for 
a number of static checks 
https://blog.kitware.com/static-checks-with-cmake-cdash-iwyu-clang-tidy-lwyu-cpplint-and-cppcheck/

My thoughts were to have a `build-webkit –static-analysis` flag that would do 
non-unified builds as well as potentially adding in dummy .cpp files for 
headers without an associated .cpp. It would run clang-tidy and 
include-what-you-use.

From: webkit-dev  On Behalf Of Darin Adler
Sent: Saturday, September 1, 2018 7:26 PM
To: Simon Fraser 
Cc: WebKit Development 
Subject: Re: [webkit-dev] Unified sources have broken our #include hygiene

On Sep 1, 2018, at 5:14 PM, Simon Fraser 
mailto:simon.fra...@apple.com>> wrote:

Unified sources allow you to get away without #including all the files you need 
in a .cpp file, because some earlier file in the group has probably already 
included them for you.

This means that when you add a new file to the build, and the unified sources 
get shuffled around, you end up with a long list of build breakages, some 
platform-specific, that you can only fix by repeating EWS trials.

Yes.

We knew this was going to happen when evaluated the proposal before we switched 
to unified sources. I believe you can find some discussion of it in webkit-dev.


How can we solve this?

I don’t think we should try to solve it.

To me at the moment, this seems to be a minor irritation. Even without unified 
sources, it’s common to get includes wrong for platforms other than the one you 
are testing on and find this out only when building on EWS.

I would be OK having an EWS server that builds various platforms without 
unified sources, but while it might help it might also hurt, adding more EWS 
results to interpret for each patch, and also finding theoretical problems that 
don’t affect any platform.

If there’s a tool that can figure out what files need to be included by 
analyzing source code, and that works well enough to be practical, I’d love to 
arrange it so that we can use that instead of having programmers have to write 
their own include statements. I’ve long been interested in 
 and wondered whether we could use it, but it 
sort of does the opposite, and the “multiple platforms” problem could well make 
even that tool impractical for us.

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

Re: [webkit-dev] Intent to land PlayStation port

[Don . Olmstead]

The PlayStation is x64. No JIT in the initial implementation.

From: fpi...@apple.com 
Sent: Monday, October 29, 2018 2:29 PM
To: Olmstead, Don 
Cc: WebKit Development 
Subject: Re: [webkit-dev] Intent to land PlayStation port


On Oct 29, 2018, at 2:19 PM, 
don.olmst...@sony.com wrote:

Hello WebKittens,

We've been working hard on our WinCairo port of WebKit and would like to begin 
landing our PlayStation port to trunk. We have opened a meta bug at 
https://bugs.webkit.org/show_bug.cgi?id=191038 for the work.

We would like to land patches individually for each component of WebKit 
starting with JavaScriptCore and making our way through to WebKit and 
LayoutTest support for the platform. Once we start landing we will be working 
on BuildBot support for PlayStation internally with the intent of creating 
public BuildBots and then look into EWS support. Until that time we will not 
have an expectation that anyone's patches should keep the PlayStation green and 
will fix any build errors ourselves. This would be a similar situation that 
WinCairo had before we started adding build and test infrastructure.

We do not plan to abandon WinCairo after we land a PlayStation port. We plan on 
continuing development on WinCairo to support our developers who use our 
PlayStation WebKit port. For example a remote inspector implementation is 
forthcoming from us and this would be used to communicate with the device.

I should have a patch for JSC this week and am able to address any concerns 
before we land that patch.

32-bit or 64-bit?

JIT or no JIT?

-Filip


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

[webkit-dev] Intent to land PlayStation port

[Don . Olmstead]

Hello WebKittens,

We've been working hard on our WinCairo port of WebKit and would like to begin 
landing our PlayStation port to trunk. We have opened a meta bug at 
https://bugs.webkit.org/show_bug.cgi?id=191038 for the work.

We would like to land patches individually for each component of WebKit 
starting with JavaScriptCore and making our way through to WebKit and 
LayoutTest support for the platform. Once we start landing we will be working 
on BuildBot support for PlayStation internally with the intent of creating 
public BuildBots and then look into EWS support. Until that time we will not 
have an expectation that anyone's patches should keep the PlayStation green and 
will fix any build errors ourselves. This would be a similar situation that 
WinCairo had before we started adding build and test infrastructure.

We do not plan to abandon WinCairo after we land a PlayStation port. We plan on 
continuing development on WinCairo to support our developers who use our 
PlayStation WebKit port. For example a remote inspector implementation is 
forthcoming from us and this would be used to communicate with the device.

I should have a patch for JSC this week and am able to address any concerns 
before we land that patch.

Thanks in advance,
Sony WebKit Team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Intent to land PlayStation port

[Don . Olmstead]

First patch is up at https://bugs.webkit.org/show_bug.cgi?id=191072

From: webkit-dev  On Behalf Of 
don.olmst...@sony.com
Sent: Monday, October 29, 2018 2:20 PM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Intent to land PlayStation port

Hello WebKittens,

We've been working hard on our WinCairo port of WebKit and would like to begin 
landing our PlayStation port to trunk. We have opened a meta bug at 
https://bugs.webkit.org/show_bug.cgi?id=191038 for the work.

We would like to land patches individually for each component of WebKit 
starting with JavaScriptCore and making our way through to WebKit and 
LayoutTest support for the platform. Once we start landing we will be working 
on BuildBot support for PlayStation internally with the intent of creating 
public BuildBots and then look into EWS support. Until that time we will not 
have an expectation that anyone's patches should keep the PlayStation green and 
will fix any build errors ourselves. This would be a similar situation that 
WinCairo had before we started adding build and test infrastructure.

We do not plan to abandon WinCairo after we land a PlayStation port. We plan on 
continuing development on WinCairo to support our developers who use our 
PlayStation WebKit port. For example a remote inspector implementation is 
forthcoming from us and this would be used to communicate with the device.

I should have a patch for JSC this week and am able to address any concerns 
before we land that patch.

Thanks in advance,
Sony WebKit Team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Clarifying feature flags

[Don . Olmstead]

Hi WebKittens,

After I saw that CSS_PAINTING_API wasn't exposed in CMake I took a stab at 
looking into the different ENABLE_ flags inside WebKit's source to try and get 
what's exposed on the XCode side synced. I ended up searching through the 
source code and found around 200 different ENABLE_ flags.

https://bug-191167-attachments.webkit.org/attachment.cgi?id=353663 has the 
listing. It was just generated by blindly greping the source code with Python.

I'm wondering if there's any way to get a better taxonomy on these things. I 
know there are other macros like HAVE and USE which some of these options might 
better fit into.

Some flags seem to be around internal debugging like ENABLE_YARR_JIT_DEBUG and 
a bunch of stuff looks applicable to JSC debugging. So as an example maybe 
DEBUGGING(YARR_JIT) might be a better way to flag things. Then maybe 
build-webkit can have some flags which enable different debugging scenarios.

Some flags are tied to ports. Only Apple ports are going to have support for 
ENABLE_APPLE_PAY and ENABLE_WEBMETAL. Maybe those should be under HAVE_ or USE_ 
or perhaps there's a way to better convey that its definitely port specific. 
This is probably dependent on whether it's something you'd want to toggle.

Then there are features that are in various states.

Some for sure are complete but you may want to turn off or on like WebGL or 
video support based on your platform. For those there should definitely be an 
ENABLE or maybe FEATURE might be a better way to designate it when A port has 
shipped an implementation.

Some are not port specific and can be turned on when complete, 
YARR_JIT_BACKREFERENCES, sticks out that it is likely going to be removed once 
the tests all pass. Maybe DEVELOP or EXPERIMENTAL would be a better 
designation. If it requires a port to do some work to enable it then perhaps 
that information can be passed along as well.

There's also some stale code like enabling web components in the perl and stuff 
like ENABLE_ACCESSIBILITY in the CMake that are just hanging out without 
actually doing anything.

Anyways those are just some thoughts on how we might be able to get things a 
bit more under control and clue developers in a bit more on what things are so 
they can utilize it all.

As a side effect perhaps we can also get more tooling around this so we can 
also keep the XCode and CMake bits in sync. I was messing around with some code 
generation in python around it and I'd be happy to throw those up as patches if 
there's interest.

I'm really interested in other people's thoughts on this.

Thanks
Don

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

Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

[Don . Olmstead]

It’s weird that we have ENABLE(ACCESSIBILITY) and HAVE(ACCESSIBILITY) so at the 
very least one of these should go away, probably HAVE.

Currently there are actual implementations for iOS, Mac, Windows, and ATK. The 
WPE implementation is just a stub with everything notImplemented. I did some 
work to make the WPE implementation just be the default at 
https://bugs.webkit.org/show_bug.cgi?id=190608 but it broke a build so I rolled 
it out and haven’t returned to it yet so this is good timing for the discussion 
as that’ll influence what needs to be done with that.

If a stub implementation is ok for ports without an actual accessibility 
implementation then I’d say remove both flags. Then downstream users would 
never have to worry about breaking due to AX signatures changing.

If not my vote is to just have ENABLE(ACCESSIBILITY) since it can then be 
toggled on and off with webkit-build. A company like Tesla could always provide 
a buildbot that turns off accessibility on a public port if this is a real pain 
point since all public ports have it enabled.


-  Don

From: webkit-dev  On Behalf Of Timothy 
Hatcher
Sent: Wednesday, November 14, 2018 7:06 PM
To: Ryosuke Niwa 
Cc: WebKit Development 
Subject: Re: [webkit-dev] Remove HAVE_ACCESSIBILITY

It wasn’t added for Tesla. But they did build with it disabled at the time I 
lasted worked on it. It was a frequent pain point to keep the build working 
when AX changes happened.
— Timothy Hatcher

On Nov 14, 2018, at 5:29 PM, Ryosuke Niwa 
mailto:rn...@webkit.org>> wrote:
I think it was added for Telsa's private port. Probably not worth maintaining 
the flag if the maintenance cost is high but is it?

- R. Niwa

On Wed, Nov 14, 2018 at 5:19 PM Fujii Hironori 
mailto:fujii.hiron...@gmail.com>> wrote:
Hi webkit-dev,

It seems that all port defines HAVE_ACCESSIBILITY=1. Can I remove all code for 
!HAVE(ACCESSIBILITY)?

https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Platform.h?rev=237992#L648

  #if PLATFORM(COCOA) || PLATFORM(WIN) || PLATFORM(GTK) || PLATFORM(WPE)
  #define HAVE_ACCESSIBILITY 1
  #endif

Bug 21802 – Rename HAVE_ACCESSIBILITY to ENABLE_ACCESSIBILITY
https://bugs.webkit.org/show_bug.cgi?id=21802

-- Fujii

___
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] Clarifying feature flags

[Don . Olmstead]

Any thoughts on what it would look like? If there are preferences we can work 
off of that.

From: webkit-dev  On Behalf Of Simon Fraser
Sent: Monday, November 5, 2018 11:41 AM
To: Olmstead, Don 
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Clarifying feature flags

On Nov 5, 2018, at 6:01 PM, don.olmst...@sony.com 
wrote:

I'm really interested in other people's thoughts on this.


Agreed that this would be great to clean up. We’ve accrued a lot of junk in 
this area.

Simon



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

[webkit-dev] What goes in FeatureDefines.xcconfig

[Don . Olmstead]

Hi WebKittens,

Recently I did some work around syncing the contents of FeatureDefines.xcconfig 
and WebKitFeatures.cmake, https://bugs.webkit.org/show_bug.cgi?id=191167 . 
Michael mentioned someone noticing that ENABLE(RESOURCE_LOAD_STATISTICS) didn't 
end up in that list. I did some digging and saw that it ended up in Platform.h, 
https://bugs.webkit.org/show_bug.cgi?id=189959 . So what I'm wondering is what 
is the criteria for something being in FeatureDefines.xcconfig and whether 
ENABLE_RESOURCE_LOAD_STATISTICS meets it.

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

Re: [webkit-dev] WebCorePrefix.h vs. config.h

[Don . Olmstead]

There was some work done by aperez to try and enable precompiled headers on all 
platforms at https://bugs.webkit.org/show_bug.cgi?id=139438 which never landed. 
I always thought of WebCorePrefix.h as a precompiled headers sort of 
optimization.

Last time I checked though there was definitely an issue with how up to date 
things were in that file and statement that “the project should be able to 
build without this header, although we rarely test that.” Is definitely false.

From: webkit-dev  On Behalf Of Fujii 
Hironori
Sent: Sunday, December 9, 2018 10:35 PM
To: Webkit Development List 
Subject: Re: [webkit-dev] WebCorePrefix.h vs. config.h


On Sun, Dec 9, 2018 at 8:22 AM Darin Adler 
mailto:da...@apple.com>> wrote:
Best would be to eliminate “config.h”: Change “config.h” into an empty file 
first, then remove all “config.h” includes, and then remove the file. But to do 
that, we need to make sure every build system for WebKit supports prefix 
headers. I don’t know how close to that we are. Maybe close? How can we quickly 
find out?

 GCC and Clang support '-include ' option.

  
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
  
https://clang.llvm.org/docs/ClangCommandLineReference.html

GTK and WPE ports are using it only in WK2 since r163032.

  
https://trac.webkit.org/changeset/163032

MSVC has /FI option.

  /FI (Name Forced Include File) | Microsoft Docs
  
https://docs.microsoft.com/en-us/cpp/build/reference/fi-name-forced-include-file?view=vs-2017

Unfortunately, it seems that MSVC's precompiled header needs to be included 
explicitly.

  /Yu (Use Precompiled Header File) | Microsoft Docs
  
https://docs.microsoft.com/en-us/cpp/build/reference/yu-use-precompiled-header-file?view=vs-2017

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

Re: [webkit-dev] WinCairo EWS bots down

[Don . Olmstead]

There were some hiccups over the weekend. Rebooted some hosts and things seem 
to be coming back online.

Thanks for asking about it!

From: webkit-dev  On Behalf Of Aakash Jain
Sent: Monday, November 19, 2018 2:33 PM
To: Olmstead, Don 
Cc: WebKit Development Mailing List 
Subject: [webkit-dev] WinCairo EWS bots down

Hi Don, Sony Folks,

WinCairo bots seems to be down for last 2 days. Can someone please have a look?

https://webkit-queues.webkit.org/queue-status/wincairo-ews

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

Re: [webkit-dev] Regarding problem in building webkit2

[Don . Olmstead]

We've put a large amount of work on the cURL networking layer and are 
continuing to improve it. It's used by both the WinCairo and PlayStation port 
so it works cross platform.

I'm not familiar with the stack on Haiku but it would require OpenSSL, we use 
LibreSSL in both, nghttp2 for HTTP/2, and libpsl for Public Suffix List 
support. You can also compile with brotli support as well for better 
compression over zlib.

-Original Message-
From: webkit-dev  On Behalf Of Konstantin 
Tokarev
Sent: Monday, February 25, 2019 4:25 AM
To: Rajagopalan Gangadharan ; webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Regarding problem in building webkit2



25.02.2019, 14:06, "Rajagopalan Gangadharan" :
> Hello,
>
> I am trying to build webkit for haiku and I stumbled upon an error
>
> The error is in “Source\WebKit\UIProcess\WebsiteData\WebsiteDataStore.cpp” 
> line 2080 says about missing platformSetNetworkParameters function and I saw 
> it was defined for CURL and SOUP only. Should I use the function defined 
> under them or should I write it to be haiku specific(platform specific) if so 
> what should be the contents of it. Thank you!

It depends on how your network stack works. In order to reduce maintainance 
cost you should consider using network stack supported by upstream, i.e. soup 
or curl

--
Regards,
Konstantin
___
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] WinCairo Intent to Deprecate WebKitLegacy

[Don . Olmstead]

Hi WebKittens,

Since taking over development of the WinCairo port we've made a lot of good 
progress with enabling Modern WebKit on Windows. Because of that we plan on 
beginning to remove support of WebKitLegacy on the WinCairo port and switch to 
a fully Modern WebKit implementation. This will enable us to use new web 
features such as Service Workers which are unavailable through WebKitLegacy.

In the near future we plan on moving our bots to using WebKitTestRunner for 
testing WinCairo. After that is completed we will be working on removing 
WebKitLegacy from the WinCairo build. I've made a tracking bug at 
https://bugs.webkit.org/show_bug.cgi?id=194904 for the work around this plan 
and we will update it as work continues towards this goal. If you are using 
WinCairo in your product we ask that you subscribe to that bug and engage with 
us there.

Thanks,
Sony WebKit Team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unified source builds and adding or removing files...

[Don . Olmstead]

The ability to toggle unified builds on and off was enabled in 
https://trac.webkit.org/changeset/239561/webkit . Immediately afterwards this 
bug was opened https://bugs.webkit.org/show_bug.cgi?id=193073 which needs to 
get resolved. We're open to adding a bot with ENABLE_UNIFIED_BUILDS=OFF if 
things compile.

From: webkit-dev  On Behalf Of Tim Horton
Sent: Tuesday, March 19, 2019 4:02 PM
To: Said Abou-Hallawa 
Cc: WebKit Development Mailing List 
Subject: Re: [webkit-dev] Unified source builds and adding or removing files...

We already had this discussion; see the thread titled "Unified sources have 
broken our #include hygiene"


On Mar 19, 2019, at 3:48 PM, Said Abou-Hallawa 
mailto:sabouhall...@apple.com>> wrote:

I have been working on patches that require adding and removing cpp files from 
WebCore/Sources.txt. Almost every time I add or remove a file, I hit undefined 
symbol compilation error in some unrelated source or header file. Because a 
group of source files are compiled in one unified source file, some 
dependencies get hidden.  The same symbol is defined in another source or 
header file. Once sources are moved to different unified sources, the problem 
gets uncovered.

For example the file svg/graphics/filters/filters/SVGFEImage.h uses the class 
TreeScope without forward declaring it or including its header file. Oddly the 
source file svg/graphics/filters/filters/SVGFEImage.cpp compiles in the trunk 
right now. If a file is added to or removed from WebCore/Sources.txt such that 
this source is moved to another unified source, the compiler will give an error 
that TreeScope is not defined.

Another example is  which fixes a 
compilation error on GTK port. The same file was compiling fine on macOS but it 
failed on GTK.

Can we fix this issue? The fixes for such errors look very mysterious in the 
patches. It can also cause build breaks because the ports do not compile the 
same files.

One naive solution is to have the EWS bots compile without the unified source 
builds. In this case, all the header and source files must have the required 
forward declaration and/or the header file inclusion. So adding or removing 
files should not affect the ability to compile any other source file.

Thanks,
Said

___
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] Moving to Python 3

[Don . Olmstead]

Mentioned this on the other thread but here’s it again.

https://python-modernize.readthedocs.io/en/latest/ and 
http://python-future.org/automatic_conversion.html might be of use considering 
the sheer amount of code. They’re both mentioned in 
https://docs.python.org/3/howto/pyporting.html for migration.

You can run individual rules one by one over the code. That might be ok rather 
than running all the rules at once. Especially for review. Modernize seemed to 
work pretty well but it wasn’t smart enough to detect shebang lines.

From: webkit-dev  
On Behalf Of Tim Horton
Sent: Friday, July 12, 2019 12:38 PM
To: Jonathan Bedard 
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Python 3




On Jul 12, 2019, at 12:18 PM, Jonathan Bedard 
mailto:jbed...@apple.com>> wrote:

Hello WebKit developers,

Now that the Catalina developer seeds are available, it is official that the 
new Mac developer tools come with Python 3. As a result, we need to continue 
the ongoing discussion about migrating our Python 2.7 scripts to Python 3.

I propose that, over the next 9 months, we do the following:

1. Make any no-cost Python 3 compatibility changes, in particular
- print foo -> print(foo)
- import .foo -> import webkitpy.foo
2. Convert any scripts not used in automation to Python 3 ASAP (scripts like 
bisect-builds, block-spammers, compare-results)
3. Make most Python 3 compatibility changes which sacrifice efficiency, subject 
to a case-by-case audit. These would be things like:
- dict.iteritems() -> dict.items()
- dict.items() -> list(dict.items())
4. Install Python 3 on macOS Sierra and Mojave bots
5. Convert peripheral automation scripts to Python 3 1-by-1 (scripts like 
clean-webkit, merge-results-json, webkit-patch)
6. Convert testing scripts and webkitpy to Python 3 in a single change

The trouble I foresee us encountering with any scheme which attempts a 
conversion which retains both Python 2.7 and Python 3 compatibility is code 
like this:

for expectation_string, expectation_enum in 
test_expectations.TestExpectations.EXPECTATIONS.iteritems():
...

In this code, the EXPECTATIONS dictionary is thousands of elements long. In 
Python 2.7, iteritems() gives us an iterator instead of creating a new list, 
like items() would. In Python 3, iteritems() doesn’t exist, but items() does, 
and now gives us an iterator instead of creating a new list. The trouble here 
is that, in this case, creating a new list will be very expensive, expensive 
enough that we might manage to impact the testing run. There isn’t really an 
elegant way around this problem if we want to support both Python 2.7 and 
Python 3, other than defining different code paths for each language.

The official Python 3 transition documentation has a fairly elegant solution to 
this, actually??

https://legacy.python.org/dev/peps/pep-0469/

See "Migrating to the common subset of Python 2 and 3” — you define different 
iteritems() helpers in the two cases. Seems pretty reasonable to me.


There are other small gotchas as well. For example, ‘%’ is no longer a 
protected character, which can actually change the behavior of regexes. That’s 
why I think it’s better to just try and directly convert things instead of 
attempting to be compatible with both Python 2.7 and Python 3.

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

[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