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 <weinig@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