Re: [webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Fujii Hironori]

On Sun, Oct 18, 2020 at 2:00 AM Sam Weinig  wrote:

>
> What are your thoughts on this?
>

I'm disappointed. I want to use CMake for all ports.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Reducing / removing use of Makefile based DerivedSources.make

[Sam Weinig]

Hi webkit-dev,

I’d like to propose, and gauge feedback on, reducing (with the goal of 
ultimately removing) the use of Makefile based DerivedSources.make.

My understanding is that currently only the Xcode based ports still use 
DerivedSources.make, as all the CMake based ones have moved derived source 
generation to within CMake, so that should limit the scope of who this might 
affect.


Why do we use Makefiles today?

While I can’t recall the initial reasons for using Makefiles for derived 
sources, over the years there have been a number of advantages to it that I do 
know of. One clear advantage, that is no longer applicable, was code sharing, 
as earlier in the project, at least the Apple Windows port did utilize these 
Makefiles. Another was to work around some limitations in what dependencies 
Xcode was able to track with build rules. It seems at least some of the 
problems with build rules are no longer an issue, as we can now specify inputs 
to build rules, but I don’t if other problems will still be there, but for some 
prototyping I did, nothing yet has come up.


What would we move to?

As this only affects the Xcode based ports, we would move to distinct script 
phases and build rules in the Xcode project.  


Why make this change? What’s the benefit?

There are few reasons to consider this. One advantage is simplifying the build 
system. Rather than two dependency systems (one for Xcode, one for the 
Makefile) we reduce it down to one. And with additional knowledge of the stages 
and dependencies, Xcode could potentially parallelize more phases. We would 
would also save some time by avoiding invoking make in the first place. 

We also have a bit of an issue with make itself, as due to system requirements, 
we are forever stuck with Make 3.81, which is coming up on being 15 years old. 
More than once in the last year I have tried to troubleshoot makefile issues, 
looking for resources on the web, only to be stymied because the solutions I 
found required newer make.


What are the downsides?

One potential downside will be that it will be a bit harder for those without 
Xcode to add new types of derived sources. I am not sure how much a real 
problem in practice this will be, as editing project.pbxproj files is already 
required for just adding new files, but I want to call it out anyway.


What are your thoughts on this? Are there additional reasons we might want to 
stick with or move away from Makefile based derived sources?

Thanks,
-Sam

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

Re: [webkit-dev] in WebKit?

[Antti Koivisto]

Seems like a sensible change. Are there WPT tests for this behavior already?


  antti

On Fri, Oct 16, 2020 at 8:06 PM Anders Hartvoll Ruud 
wrote:

> Hi,
>
> We are about to ship support for :is() and :where() in Chromium, including
> support for .
>  As
> far as I understand, :is() in Safari 14 takes a regular ,
> and Chromium API owners are concerned that this is a potential source of
> interop problems.
>
> Are there any plans to implement the  behavior in
> WebKit as well?
>
> Thanks,
> Anders
>
> FYI: https://bugs.webkit.org/show_bug.cgi?id=217814
> ___
> 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