On Sat, Oct 17, 2020 at 10:00 AM Sam Weinig <wei...@webkit.org> wrote:
> 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.

Do we need to dig up some kind of bespoke Xcode UI to add a new IDL
file after this? I always find all those build phase things in Xcode
to be impossible to edit.

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

Is there some way we can use something like Sources.txt to list the
files from which derived sources are created? DerivedSources.make is
annoying to edit but the equivalent CMake file is equally annoying to
edit. If we had a simple list of files like we do for unified sources,
it would make an average WebKit contributor's life way easier.

- R. Niwa
webkit-dev mailing list

Reply via email to