Re: [webkit-dev] Finding when a platform was dropped

On Apple platforms, we do not specifically “turn off” support for older OSes. WebKit’s build is configured to deploy to whichever SDK version you have installed. That said, you can see when we stop building for a specific OS version in our continuous integration, which is a good indicator of

Re: [webkit-dev] New status field required for feature flags

> On Jan 10, 2023, at 06:39, Michael Catanzaro wrote: > > Different default values for different ports is unavoidable; there are many > many other examples besides PDF.js where ports just need to be different. But > I think it's OK for the status field to be the same on all platforms. Just >

[webkit-dev] New status field required for feature flags

Hi webkit-dev, Brent (CC’d) and I are rolling out changes to how we represent feature flags in WebKit. As of https://commits.webkit.org/258448@main, the WebPreferences*.yaml files have been merged to one feature list: Source/WTF/Preferences/UnifiedWebPreferences.yaml Instead of having

Re: [webkit-dev] webkit-dev Digest, Vol 208, Issue 5

> On Sep 29, 2022, at 18:54, Ryosuke Niwa via webkit-dev > wrote: > >> Introduction.md is definitely not the right place for much of this, so that >> leaves the GitHub Wiki (which, I might point out, was never discussed as a >> community either, I started it so we could discuss migrating

[webkit-dev] Xcode workspace builds enabled by default in build-webkit; expect faster build times

Hi folks, As part of ongoing work to adopt Xcode’s modern build system, I have turned on “workspace builds” by default for build-webkit as of . When building for Mac, iOS, watchOS, or tvOS (including builds made by EWS bots), expect build times to drop,

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

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

Re: [webkit-dev] OK to flatten WTF's header directory?

Thanks for the detailed response! I should be clear that I don’t have a strong opinion for or against flattened headers, I’m just interested in ironing out a perceived inconsistency. > On Feb 3, 2022, at 15:31, Darin Adler wrote: > > Long ago, I originally created the forwarding headers to

Re: [webkit-dev] OK to flatten WTF's header directory?

> On Feb 1, 2022, at 22:12, Tim Horton wrote: > > Question: If they're flattened in the SDK, and not flattened in the source > tree, which include path do we use when including a WTF header in e.g. > WebCore? > > Right now you say `#include `. In your world, would you > say `#include `?

[webkit-dev] OK to flatten WTF's header directory?

Hi webkit-dev, I’m working on fixing some ambiguities in our Xcode projects to permit adoption of Xcode’s new build system and better parallelize our builds. I noticed that WTF’s headers (/usr/lib/include/wtf) are atypical in that they aren’t copied into a single directory – they’re deeply