Please note that this is a Cocoa-only, Xcode-only conversation.

As Sam pointed out, there’s a whole different “will you please switch to CMake” 
conversation. That’s not an easy switch to make for programmers working on the 
Apple platforms, but we might do it at some point if we can work out the issues 
Sam mentioned.

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

Pretty sure I was the one who did this. And I do recall the initial reasons. 
There were only two.

1) Code sharing

I believed at the time that the rules for building derived sources were tricky 
and hard to get right, and proposed that we would use the 
lowest-common-denominator build system, make, across all platforms. This 
strategy didn’t work because right from the beginning people working with 
various build systems used copies of the derived sources rules that I wrote 
rather than invoking make, and never tried sharing code.

I think this was a missed opportunity to share complicated code, but it 
happened a very long time ago, and I made my peace with it back then.

2) Xcode build system deficiencies

At that time, Xcode’s build system had too many problems for these kinds of 
complex rules. Many years later, that may no longer be true.

Since we’re not even trying to do the code sharing, I think it’s fine to stop 
using makefiles now.

If we’re deeply committed to switching to CMake at some point in future, one 
way to take a step in that direction would be to return to the original code 
sharing goal, and use CMake for derived sources, so we have code sharing. I 
don’t know how modular CMake is and how practical it is to use it for part, but 
not all, of the build process with Xcode. People using CMake for everything 
might be frustrated with the constraints this could place on how CMake is used.

I think an important third goal that I did not have at the start, but have now, 
is the one Ryosuke mentioned:

3) Minimize the number of places files are listed, so it’s easy to add, remove, 
and rename files of various types.

It would be wonderful to drastically cut down the repeated mentions of the same 
filenames. People not on Xcode platforms probably focus primarily on Xcode 
projects for this frustration. But I find it ridiculous how many places I have 
to add things. For example, to add AbstractRange I had to add filenames to:

Shared:

Sources.txt

CMake:

CMakeLists.txt
Headers.cmake

Xcode:

WebCore.xcodeproj/project.pbxproj

And also, the checked-in generated files (that we’d need regardless of build 
systems, due to Apple build requirements):

DerivedSources-input.xcfilelist
DerivedSources-output.xcfilelist

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

Reply via email to